New Product Development with Lean Startup and Scrum

By Roman Pichler, 27th June 2013

Discovering Lean Startup was inspiring for me: I felt I had found an approach that could complement Scrum nicely. Since then I have been combining the two approaches in my own new product development work as well as helping my clients to do so. This post shares my experiences and insights. It maps out a high-level process for creating new products within existing businesses focussing on product management practices and tools.


From Vision to Launch

Lean Startup encourages us to first investigate if there is a need worthwhile serving before we worry about the details of the new product. The former is called “Problem Validation”, the latter “Solution Validation”. While traditional approaches also suggest carrying out market research and analysis before we engage in product planning and definition, lean approaches increase the speed at which we operate. This allows us to fail and learn faster, to adapt our product strategy and tactics quickly, and to hopefully launch the right product with the right features sooner.

The following diagram illustrates the process I apply to create new products:


Problem Validation

The new product development process depicted above starts with a vision. It then uses a series of cycles or iterations to transform the vision into a product ready for launch. The focus of the early iterations is to understand what problem the product solves, who the customers and users are, and how the product benefits the company creating it.

I find it important that the product owner leads this effort and carries out the necessary work together with a cross-functional team. While the team composition depends on the product, having a marketer, sales representative, service representative, a UX designer, and a developer on board is usually helpful. Product owner and team capture their assumptions about the market by using a tool like the Vision Board, Business Model Canvas, or Lean Canvas.

Employing techniques such as direct observation, problem interviews, and competitor analysis helps them validate their assumptions and update the board or canvas, as the following pictures illustrates:

Additionally, the developers may create spikes (throwaway prototypes) to explore the feasibility of the product. Target users and customers participate in the process, for instance, by acting as interview partners.


Solution Validation

Once product owner and team have shown that there is a problem that’s worthwhile addressing, the focus changes to validating the solution and developing the actual product: The team needs to learn what the desired user experience is, what functionality the product should provide, and how it should be built.

The new focus requires adapting the team composition: The product owner, the UX designer and the developer stay, but the marketer, sales and service representatives leave the team. They continue to participate in the development effort as stakeholders. New developers, testers, and other roles required to create a great product join the team.

Product owner and team capture their assumptions about the product including the user interaction, the user interface design, the functionality, and the nonfunctional aspects using a tool like the Product Canvas and techniques such as scenarios, user stories, and design sketches. The assumptions are tested by collecting and analysing feedback on prototypes, mock-ups, and product increments/MVPs. Useful techniques to gather the feedback include product demos, users tests, and releases (to selected users).

As you may have noticed, the picture above suggests that “Stakeholders incl. users” participate in the process, and provide feedback or data on work results. While using target users and customers to validate ideas is generally helpful, it is not always appropriate. Imagine addressing a key technical risk in your first solution validation iteration: It probably makes little sense to invite users to the review meeting to understand if the approach chosen is viable. Similarly, if a disruptive product is developed it can be hard to find target users that are not too attached to their current solution.


Scaling and Launch Preparation

Once the Product Canvas and the architecture have started to stabilise, you can start adding more people to the project. I find it useful to break-up the original team so that at least one or two members are part of each new team, as this helps the new members get up to speed. I also suggest you grow your new product development project in a step-wise fashion: Scale from one to two teams, then from two to four, and so forth. This allows you to understand the impact on the people and the process including product ownership .

Be aware of the danger of premature scaling: Adding too quickly too many people. This tends to lead to a bloated, over-engineered product in my experience, and it prevents you form being able to experiment effectively. Therefore delay scaling until you have resolved the main risks – until you can focus on completing features and adding new ones.

Finally, as you make progress with your solution validation work, don’t forget to prepare the product launch. Having a marketer present at the sprint review meetings should help, but you may find that a dedicated marketing may be required to prepare and execute the launch well.


Bringing it All Together

The following table summarises my recommendations for transforming an idea into a shippable product:

The process described in this post is based on work by Steve Blank, Ash Maurya, Eric Ries, and Ken Schwaber. The eagle-eyed process historians amongst you may have noticed that the idea of progressive scaling has its roots in the (Rational) Unified Process. Experimental, iterative product development has been around for quite some time of course, I believe at least since the late 19th century when Thomas Edison established the Menlo Park laboratory.


Learn More

You can learn more about combining lean and agile techniques to create new products by:

 

Summary
Article Name
New Product Development with Lean Startup and Scrum
Description
This article describes how combining Lean Startup and Scrum can help you create new products.
Author
Pichler Consulting

Source: http://www.romanpichler.com/blog/new-product-development-with-lean-startup-and-scrum/

RSS Feed

12 comments on “New Product Development with Lean Startup and Scrum

  1. Susma

    Hi Roman,
    I landed to article from a reference in your article about checklist for a product owner before starting a sprint and with the title of the aticle, I had expected some details on how long to follow lean start up methods and switch to development sprints. I understand some people talk about sprint 0 but sometimes the starting phase may really take some time. Some inputs on a good way to distinctly divide the steps would have been great.

    Thanks,
    Susma

    • Roman Pichler

      Thanks or you comment, Susma. Unfortunately, I cannot state a specific timeframe, such as one sprint, as the problem validation or product discovery work required does vary. It depends on the innovation type and product life cycle stage, as I explain in my book Strategize. In sum, the more uncertainty and change is present, the more validation work is required. This ranges from a few days to several months. Hope this helps!

  2. Mark

    Just a read a very interesting article about how a company can be considered lean if its improvement efforts result in layoffs? Michael Ballé, PhD answers this frequently asked question drawing from his own experience dealing with organizations. http://www.planet-lean.com/the-layoffs-taboo

    • Roman Pichler

      Hi Mark, Thanks for your comment. I believe that the goal of any improvement effort should ultimately be to help a company create more value and not to lay people off. As far as I know, the term “lean” was coined to refer to an environment where wasteful work (Japanese muda) is eliminated, overburden (muri) is avoided, and unevenness (mura) in the work is reduced thereby creating a smooth, levelled workflow. Hope this help.

  3. Scott Cable

    Hi Roman,

    I came across your very interesting article last year. A similar distinction between the problem domain and the solution domain can be found in npd literature – between the “fuzzy front end” and the “execution-oriented back-end” – see Menor, L. J., Tatikonda, M. V., & Sampson, S. E. (2002). New service development: areas for exploitation and exploration.

    • Roman Pichler

      Hi Scott, Thanks a lot for your feedback. I am glad that you like the post. Thanks also for the reference. I don’t view problem and solution validation are not phases or stages in the traditional sense with a hard stop such as a milestone or gateway. They can overlap and form a continuum. Does this make sense?

      • Scott Cable

        Understand and agree with the continuum point – the domains I mention describe biases or orientations in terms of the activities executed, rather than discrete phases with a hard stop or transition or gateway. And sure, there can be overlaps, as well as reversal in direction.

  4. Shannon Lewis

    This is an excellent article. I could have used this when I was working to redefine the new product idea process back in the old “waterfall” days. One thing we found very important is treating all product ideas equally. All too often “pet projects” would have different rules than the rest of the world and were funded too long and cost the company time and money. Having set criteria that all projects have to follow is key to success. I wrote about how I changed the new product idea process back in the waterfall days. If you think this might be interesting you can find the blog here: http://www.panopticdev.com/blog2014/optimizing-your-new-product-idea-pipeline/

    Where does the financial analysis come into play in your model?

    • Roman Pichler

      Hi Shannon, Thanks for your feedback. I am glad that you find my post useful. I view financial analysis is part of creating and validating the business model. Does this make sense?

      • gokhan

        I am curious about the same.

        Because product owners replace inbound product managers, right? if so, they should be able to build business cases. Am I wrong?
        Calculating NPV, ROI or IRR sometimes?

        Thanks

        • Roman Pichler

          Hi Gokhan, Thanks for your comment. I agree that product owners should take charge of the business model (possibly with the help of people form other business groups such as finance).

          How you define and measure value depends on your product, your business model, and your organisation. I like to use my GO product roadmap to formulate product goals and metrics/KPIs: http://www.romanpichler.com/tools/product-roadmap/ If, for instance, the goal of the first product version is to acquire customers, then ROI would not be an appropriate KPI. Does this help?

  5. sherine

    Nice creation for developing an innovative new product development with lean start up and scrum.

Leave a Reply

Your email address will not be published. Required fields are marked *