Design Sprints for Business Model Evaluation

The past few months for the company I founded 3 years ago, have probably been the most interesting. We know that every company goes through phases of business model pivots, renement, and revalidation or even embrace radical new models. However, there are companies or products that are yet to fully mature – in other words they might have got some part of the mix right, such as customers and revenues, but they continue to have teething issues around other aspects such as pricing power, growth, distribution for instance. aspects. Fixing these issues is akin to doing a surgery on a moving patient. In our case, we needed a fairly radical review and thinking on the business plan to move the company forward. I have shared some of the approaches and lessons that we learnt as part of that journey. The conventional approach is to either work with existing and/or prospective customer, current and/or future needs, possibly look at re-inventing the business model based on competition or innovating within the core. We ended up with around half adozen ideas that needed some validation or review. We decided to follow the approach of Design Sprints best described in the image below.
Design Sprints Approach

Design sprints as a concept has been around for long time, but a framework for it was developed and used extensively by UX teams at Google. The idea is to quickly ideate, prototype and test before building the actual solution. It can be extended to product planning as well. Instead of assuming that your users need a specic feature or product and investing time to build and validate it, the Design Sprints approach is particularly helpful in quickly ideating, prototyping (if possible) and testing with visuals or simulated methods before building the actual solution. It is a structured approach with elements of design thinking, agile development and market research.

The key aspects of the approach as re-stated for the business model validation are:

1. Understand - What are the business challenges and the market challenges? What are the challenges around customer adoption? What do we know about our technology and team capabilities?
2. Define – What are the customer/user journeys and lifecycle? What are our focus areas? What are the non-core or partnership opportunities?
3. Diverge – How can we explore possible plans and options? What are the radical ideas including major pivots? How can we understand diversity of the entire business ecosystem?
4. Decide – Different approaches from Zen voting (silent vote before being inuenced by others). How can we use the dierent thinking hats - a pessimist hat, optimist hat, user advocate hat and the feasibility hat to decide?
5. Prototype – Detailed workows and service maps, Demos and/or simulated methods, for example manual service delivery or partner tie-ups.
6. Validate – Key external stakeholder inputs with visual and/or simulated methods using simulated services, conversations, presentations and mock agreements etc.

Some of the lessons learned in the process were:

1. Diversity of team is critical – The ideal team should comprise 5-6 people from diverse backgrounds. Fresh perspectives were added from people quite unfamiliar with the business as well as from entrenched players who had a lot of domain knowledge.
2. Why is the magical question – Asking ‘why’ at every step whether it is about user motivations, business needs or pricing assumption helps in obtaining the right feedback in the cycle. Given the shorter Idea to Feedback process, a ‘why’ at every step is critical for the evaluation.
3. Know your users – A lot of times, founders build products to solve the problems they faced and in the manner they would like to use it. But the end customer/ user reality may be very dierent from the inherent biases of the founders.
4. Zen Voting – Silent voting on presented ideas and inputs is important, to neutralize the ability of some people in the group to articulate and persuade others to their point of view.
5. Record or save discussions – It is important to record and save the discussion as replaying the conversations/ debates gives fresh perspective on the challenges or the issues at hand.
6. Sprint master’s role – Preparation at each sprint and team meetings to underline the core challenges, dene the purpose and issues was critical in keeping the momentum going.

Our sprints were little longer, say 3-4 weeks instead of 1-2 weeks, but we were able to gather feedback, evaluate using dierent approaches, and review both incremental and radical ideas. It denitely helped that we were not a brand new startup for it was little easier to get quality feedback from key partners, customers, KOLs, investors, users etc.

This re-use of design thinking tools to help assess the complex issues of exploring or revalidating potential business plans, right in the middle of a running a startup business is truly something worth considering.