We all know it: selecting the right tool for the right problem renders the best quality with the shortest time and least cost spent. Of course you need also to have the competence and experience using that given tool.
In a hurry? Jump directly to the Conclusion.
Product company and Solution Provider - market and optimization focus
Inspired by LeadingAgile we’ll view the optimization matrix below from the viewpoint of the Product Company and of the Solution Project Provider. Note that the “Solution Provider” need not be an external party. An internal “Service Provider” servicing the business is very common in organizations with a poorly developed Product Culture. See e.g., The Service Provider Mindset and why you do not want it.
Below we’ll assume
- the Solution Project Provider to be an external party with a simple business model: have the portfolio of Solution Projects in average provide a contribution ratio above xx%, assuming no cash-flow after a closed project, and have the projects run under a tight governance model
- the Product Company to be a major player in the market for advanced water technology products and solutions
A: Optimize for adaptability in an emergent market - home for Product Innovation
Product company
The right tool for the job: A solid Product Culture upon which a network of Product Teams conduct Product Innovation. The Product Teams are tasked with (hard) business/customer problems for which they are empowered to Discover the best solutions but held accountable for the business Outcome.
The wrong tool for the job: Trying to drive innovation with a predictability Output mindset using a classic Project approach. It should be obvious that the classic business-case driven project with success measured on the project triangle does not apply here. Despite this you’ll often hear organizations trying to do exactly that using “Product Development projects” governed by the organizations “project model”.
Solution provider
The Solution Project Provider is not accountable for the Outcome in the water technology market. Its focus is ensuring a predictable business on each Solution Project provided to the Product company; that is focus on predictable Output governed by the classic project triangle.
It is very unlikely that the Product company will outsource the innovation of a full product to the Solution Provider, for several reasons e.g.,
- the Solution Providers business model is at odds with the Product Culture in the Product company
- we’re talking a highly strategic area
The Product company might, during Product Discovery, have identified a non-strategic solution area. In the quest to focus its own critical capacity, the Product company might decide to carve-out and outsource a classic Solution Project.
B: Trying to achieve predictability in an emergent market
Product company
If you find yourself in this quadrant, the recommendation is to review your business vision and strategy.
If the product area in question is outside your strategic focus, you might want to engage a proven Solution Project Provider thus prioritizing your own critical capacity for strategic innovation.
Solution provider
The Solution Project Provider could easily be invited to quote on this type of project and tempted to quote on it. The stakes are high here and so are the potential wins. If you are a mature, focused and competent Solution Provider, this could be an interesting quadrant for you.
Do not try entering this game, if you do not have a sharply defined marked focus and understanding or, if you are not among the best.
C: A predictable business in a mature market - home for the classic Project
Product company
Applying a classic Project is also highly relevant for the high-tech Product company; just not for Product Innovation e.g.,
- Major changes to the production setup requiring a high degree of predictability; e.g., setting-up a new production site
- Delivery of well-defined customer solutions
- M&A projects
- …
The good old virtues of solid Project Management are here to stay … for some problems.
Solution provider
This is the bread & butter quadrant matching the business model for the Solution Project Provider: Deliver Output according to clearly agreed specifications.
D: Optimize for adaptability in a mature market - home for incremental changes
Product company
The situation for our high-tech water company is e.g., a stable Product/Market fit with customers requesting tailored end-to-end solutions.
For the Product company to meet these market requests, the ability to make smaller, fast but highly controlled changes to the product / production modularization is key.
The Product Team(s) will thus primarily operate in an agile delivery mode. See also Dual-track Agile.
Solution provider
Unless the Product company faces larger, clearly specified and encapsulated changes suited for outsourcing, the Solution Project Provider does not have a viable business platform here.
The "Agile Project"
The “Agile Project” is also by some named a “hybrid model”. Is this the magic potion for high-tech Product companies?
Examples are
These “hybrids” all try to position themselves as the-best-of-both-worlds models. They are all surprisingly bloated and prescriptive with their own developed terms, templates, processes, practices etc. Not much “Agile” really. You’ll find a whole ecosystem of institutions basing their business on (re-)certification, education, coaching..
In contrast, the Best Product Companies have a Minimum Viable Bureaucracy approach with as little process prescription as possible. Instead these best-in-class companies have a rich pich&use buffet with processes, tools, golden path etc. supporting their network of Product Teams and their overarching Product Culture.
Just to prove the point that you do not need big and bloated project models as a consequence of your size and success: Amazon is one of the most clean-cut examples of a successful high-tech Product company having maintained an extreme degree of business agility throughout its network of Product Teams despite its exponential growth.
The physical world and "Agile"
A relevant concern is often heard when the product is not 100% software-based: how can we ensure “continuous delivery” on the physical parts of our product?
You are of course limited by physical constraints not present in pure software, but what you can and should do when innovating a multidisciplinary product with physical dimensions is to
- use simulation models / digital twins
- use evaluation kits
- move relevant parts of hardware to software using e.g., Field Programmable Gate Arrays (FPGAs)
- maintain the fast and disciplined experiment / learn Product Culture as in pure software products
- learn from the software guys: encapsulate complexity behind stable APIs / interfaces
- test integration interfaces again and again – experience clearly shows that problems show-up here
- use the 3D printing technologies that has become both highly advanced and mature
The short answer is thus: it makes perfect sense also to apply Dual-track Agile (Product Discovery and Product Delivery) to products not purely digital.
Conclusion
The Product company has its focus on Outcome as the result of innovating and bringing the right products to the market. Contrast this to the business model of the Solution Project Provider being focused on delivering Output.
The product lifecycle in the Product company is owned by its network of Product Teams with a shared and strong Product Culture and mindset contrasting the classic Project mindset.
Even for the Product company some problems are best handled using a Project approach … the right tool for the right problem.