Product Based Approach for Single Customer Projects

Question

The article "Products over Projects" by Sriram Narayan makes the case for treating projects as products.

I can see many benefits to this and would be my preferable methodology, but the examples of 'projects' referenced in this article seem to be 'almost' products already in that they are delivering shared components that may be delivered to multiple end users. Essentially, these projects (I assume) are funded internally.

My question is: in the case where a project is funded directly by a single customer and the result is at least partially bespoke to that customer's needs, is it still feasible to apply a product-based model? Does anyone have real-world experience of doing this?

Some challenges I can see (or at least differences from a pure product model)

• Customer has an expectation of fixed scope; we aim to deliver the 'right' solution but there is some pressure to simply deliver what the customer paid for. Perhaps this indicates an issue with the sales model but where a project is delivering a solution for a single customer, this may be difficult to change.
• There is an expected time-frame for delivery. This may be set by the customer but is often related to external factors, particularly where the work is part of a larger project with its own concerns. In this case, team has less ability to juggle priorities when a piece of work comes in with its own deadline (maybe solved by an effective Product Manager?)
• A project may require changes across multiple product areas and technical domains; if work were split across multiple teams based on product or technical specialties (as suggested in the article), it would be difficult to maintain a coherent result

None of these points are complete blockers to this method but I am interested in real-world experience; can we apply a product-based approach to ANY software environment or is this not feasible?

** EDIT **

In my experience, where solutions are tailored to a single customers' requirements, a project-based approach (assemble team from a resource pool, maintain team during build phase and disband, focus on utilisation and hours delivered rather than ROI) has been used. Where a solution is intended up-front to be delivered to multiple customers, a product-based approach (stable team, product roadmap, product management, focus on ROI) has been used. This is not a judgement of the various rights and wrongs but the reality from years of work experience.

The article advocates applying a product-based approach to solutions that would traditionally be planned as projects and makes a good case for the benefits of doing so. But I am interested in whether this model can be extended to bespoke solutions for single customers. These are often complex and long-lived and treating them as projects to be delivered and not products with an ongoing lifecycle presents a number of problems.

So specifically, I am interested in whether anyone has real-world experience of implementing the approach advocated in this article (essentially moving from projects to products) and does it extend to delivering bespoke solutions to single customers? Or do we find bespoke solutions always treated as projects and not products?

Answer 1

The linked article talks about projects as a form of funding work and organizing teams. I think it would be best to refer to this as a "project-mode" (in alignment with "product-mode"), rather than considering "projects" versus "product-mode". Even for an organization operating in product-mode, projects can and do have their place for thinking about related work and value delivery.

Projects, as defined in the article, or what I would call project-mode is not compatible with product-mode. If you think about projects as a way to fund work or form (and then disband) a team, you can't think about long-lived products.

If you are operating in product-mode, you could still have projects. If you define a project as "a temporary endeavor undertaken to create a unique product, service, or result" as the PMI does, then you may use projects as a container of work and a product team may work on 0 or more projects at any point in time. Some of these projects could be bespoke work packages that are funded explicitly by a particular customer. You can use project and program management to organize projects and on-going product support work to optimize for the right attributes.

The one concern that I would have is the notion of a fixed-scope project. This doesn't tend to work well for software development and is why agile methods work. Even the US government is realizing this and is moving away from statements of work (for fixed-scope delivery) to statements of objectives (that focus on value and goals over a period, and let the work be flexible.

Although thinking about products and operating in product-mode is probably better for a lot of organizations, you can't discount project-mode, especially if you're building a lot of bespoke changes for individual customers. I'm thinking about a software shop that builds white-label web or mobile applications. They may have a core product that they fund through internal R&D as a product, but operating in product-mode for each branding would probably be inappropriate.

Both project-mode and product-mode have their places. But product-mode also doesn't mean dropping projects. Both are ways of thinking about the high-level organization of people and how to go about funding their ongoing work.

Answer 2

can we apply a product-based approach to ANY software environment or is this not feasible?

Can you? Yes.

Is it always feasible? Probably not. But this requires defining your resources and what you consider to be infeasible (i.e. outside of the boundary of your available resources). This could be cost, time, complexity, or risk factors.

My question is: in the case where a project is funded directly by a single customer and the result is at least partially bespoke to that customer's needs, is it still feasible to apply a product-based model?

Just because you only have one customer today, doesn't mean that another customer can't present themselves in the future. If you tailor it to that first customer in a way that you lock yourself in, you might lose out on that second customer (without significant rework effort)

Customer has an expectation of fixed scope; we aim to deliver the 'right' solution but there is some pressure to simply deliver what the customer paid for.

The customer should not pay for any work that is not related to delivering their product (other than general maintenance and code cleanliness). Any effort incurred by abstracting the codebase to be product-oriented and consumer-agnostic should be considered an investment by the developer('s company) for future reusability.

There is an expected time-frame for delivery. This may be set by the customer but is often related to external factors, particularly where the work is part of a larger project with its own concerns. In this case, team has less ability to juggle priorities when a piece of work comes in with its own deadline (maybe solved by an effective Product Manager?)

Some projects come with a deadline on the calendar. Other projects come with a cap on billable hours. The latter is fairly easy to spend extracurricular time on, you simply intersperse it between the billable work.

However, assuming a fixed team size, a calendar-based deadline can make it impossible to abstract from the get go. Either you need to increase your team capacity by increasing the available manhours over the given period (to reiterate, the extra cost is the investment the company makes into this), or you backlog your abstraction until you've delivered the temporarily tailored first version of the application to the customer. It's not ideal but no one every said that product-oriented approach work for everyone in every scenario.

A project may require changes across multiple product areas and technical domains

Generally; no. A product is defined by its independence from other products. If you consistently run into issues where your products impact each other; you've not separated your products correctly.