There are plenty of efforts underway in many companies to be more nimble in bringing products to market.
One aspect of this has been for physical product teams in companies that have both physical and digital products or combined physical and digital hybrid products, to take a look at what their software colleagues are doing. This is because the software folk seem to have figured out how to be very adaptable (aka being “agile" ).
As a result, the product teams behind the physical product are experimenting with digital processes and identifying new things to try in creating the physical product. And there are some really encouraging early ideas. More on that in a future post.
But often it does not go the other way around. Product teams driving digital products don't often look to their colleagues on the physical product side of the house for best practices. Those physical product teams — who have honed idea-to-launch processes for many years to bring winning products to the market — also have insights to help software teams.
In a recent article, Is Agile killing Phase-Gate? , I wrote about instances where Stage-Gate® adds significant value and should not be too quickly dismissed, and other times where it was never intended to be the way to do certain things.
Watch this webinar I hosted with the Innov8rs community.
In this article, I will expand on those ideas and discuss them in the arena of software products.
From a market - and business - perspective, software and physical products (and hybrid products incorporating parts from both worlds ) have much in common.
Bringing structure to the decision-making that is required both before and after product development leads to a more aligned and streamlined business. Product teams and executives have identified and implemented gated processes and deliverables to provide that structure.
The classic phase gate process defines work to be done to adequately define the product, its commercial value, and the likelihood of market and technical success. The processes organize the results of this work into deliverables, which are reviewed by cross-functional decision-makers. Some common deliverables, which have been used for many years for physical products and may have value for software products, include:
Opinions vary about the business case and how it may or may not stifle innovation if it is too rigorous. Some have gone to a lean business case to be refined later. Some perform a preliminary cash flow analysis as part of the business case and refine it later when the product is more defined (for example, coming out of the Agile development process when its exact capabilities are known). Scaled Agile approaches sometimes state it as a value stream to be achieved over time with successive increments. Rare are the companies that will invest without understanding the business case up front in some form or another.
An important learning from companies that excel at bringing new products to market is the cross-functional discussion, evaluation, and decision-making related to these deliverables. Find the right balance for your company, but there are good ideas here to learn from.
Completion of up-front scoping and business case stages not only enables better investment decisions, but they provide cross-functional alignment around the aim of the product. By following a bit of rigor here, the “why” of the product becomes sharper and understood more widely in the company. I have observed plenty of sprint demos where the overall aim is not well understood by those reviewing the demos. As a result, those attending the sprint demos are less effective at providing feedback and are too often focused on what has not yet been created (what is missing from their perspective) rather than on what has been achieved thus far.
Not all the deliverables that are used for physical products are applicable to software products. The ones identified above are. The core objective is to understand why we are trying to create what we are creating (the “why”) and determine if we are aligned as a company on the target of a release or new product.
Coming out of Agile or Waterfall software development, some key deliverables to create and evaluate are:
These deliverables, focused on launch readiness, are often shared more widely than just within the software teams and the software development organization. Many of the launch readiness deliverables are similar to those for physical products, and some are unique to the software world.
Finally, just as with physical products, there is the decision to launch and then the need to actually manage the launch of the software product to the market. The decision to launch should not be taken lightly. Rushing out the door now that you have the software product completed is a strong urge, but don't do it if you are not ready. Don't set yourself up for failure before you start the launch. This is where a gate decision, with the right gatekeepers, adds tremendous value.
And then, once decided, you need to perform the launch and track that you are doing what you said you would do. After that, enjoy the success!
As you can see, there is much to organize, discuss and agree on that extends beyond the borders of product development. Most DevOps tools are not good at organizing and managing such information in a governed process. This is where products such as Accolade bring value.