From Product Idea to Product Launch
From Product Idea to Product Launch
Join the DZone community and get the full member experience.Join For Free
Scrum assumes that the team is able to create a product increment in the very first sprint – working software that could be shipped. But little has been said about the agile frontend, the necessary activities to prepare the first sprint. This blog post aims to fill the gap by sketching an agile innovation process that starts with an idea and ends with a shippable product.
What happens before the first sprint? We can answer this question if we know the entrance criteria for the sprint. Ken Schwaber recommends in his book Agile Project Management with Scrum that a product vision and an initial product backlog should be available before the first sprint starts. Applying this advice results in the following process:
But the diagram above is incomplete. It considers only the “development” part of a product innovation process. Where is the frontend? Where do the product vision and the product backlog come from? If we follow the common notion that any innovation starts with the idea to create a new product or to update an existing one, we can extend the process as follows:
The diagram above sketches a process that consists of two steps: a visioning step that creates the product vision and the initial product backlog, and a subsequent “development” step that turns the vision into a product ready for launch.
At the end of visioning, following information should be available:
- What will the future product (version) roughly look like and do?
- Who are the target customers and users?
- How does the product add value?
- Why is it beneficial for the organisation to develop the product?
- Is the product feasible and how will it be roughly built?
- What are the desired product launch date and the target budget?
Answering these questions may require creating additional artefacts including an architecture vision, (throwaway) prototypes, and a business case.
Like all things agile, envisioning the product should be a collaborative effort. The product owner should lead the visioning work and involve the right people: the team members, the stakeholders, and the ScrumMaster. This approach leverages the collective wisdom of the individuals and results in a vision that is truly shared. Keep the same individuals involved while the vision is turned into a shippable product to avoid hand-offs, defects, waiting and delays, and other waste. (Note that not necessarily all team members have to partcipate in the visioning.)
Make sure to involve target customers and users early and regularly in the innovation process. Validate any idea and assumption as quickly as possible with prototypes or even better, with a product increment. Instead of trying to predict the future – something notoriously difficult for anyone not blessed with perfect foresight – let the product evolve through an ongoing dialog with its users and customers, and the other stakeholders.
Avoid the mistakes of neglecting and of overdoing the visioning work. Spending month after month with extensive upfront market research, product planning and business analysis is hardly desirable in an agile world where flux and unpredictability dominate. The following two factors allow you to understand how much visioning effort is likely to be required for your product: your product’s lifecycle stage, and its complexity – the feature set as well as the technical solution. The younger and the more complex a product is, the higher the necessary upfront investment tends to be.
When envisioning your product, focus on the minimal marketable product – a product with minimum functionality that meets the selected customer needs. This reduces the necessary visioning effort and the overall time to market. As a rule of thumb, a few hours to a few weeks – rather than many months – should be sufficient to answer the questions above.
Published at DZone with permission of Roman Pichler , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.