BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles How to Improve Product Development by Integrating Design Thinking with MVP

How to Improve Product Development by Integrating Design Thinking with MVP

This item in japanese

Bookmarks

It’s difficult to predict the success of a new product—some argue it’s impossible.  Even the largest, best funded, most mature companies have created products that fail to gain market acceptance and profitability. And as we’ve seen in numerous industries, product success can’t be guaranteed by financial investment or process optimization.

With the need to move fast in a given market and an inability to guarantee success through any means, companies continue to seek ways to manage the inherent risk in product development.

Many companies are turning to the strategy of releasing a minimum viable product (MVP). An MVP provides a limited set of core features to meet the immediate needs of a target market.

An MVP approach to product development is a strategy to quickly introduce limited-featured products to narrowly defined markets, to manage the risk of creating things customers don’t want or no longer need (which may result from delaying the release of a product until it’s fully featured to meet the needs of a broader marketplace).

Design thinking is an approach that involves the application of empathy to problem solving, matching the things people need with technologically feasible and viable solutions available today. Empathy lets us feel what it’s like to be in someone else's shoes, to create customer-centric products and solutions to meet specific customer needs. As a framework for product development, design thinking is a human-centered, interactive learning process that focuses on customers as people with defined needs, and works backward to a technology solution. This provides a level of clarity on business objectives and a deeper understanding of the way a company’s products are valued in a marketplace.

(Click on the image to enlarge it)

Companies employing design thinking are afforded the opportunity to release products more often, gather meaningful customer feedback and validate a product’s use and vision in a marketplace, while sustaining a high level of customer satisfaction, as one release builds on another to add features customers desire most.

Implementing design thinking into an MVP development can be broken down into 5 steps:

  1. Define. You need to begin the development process by clearly defining the target customer’s underlying needs, developing a deep understanding of how a prospective solution improves their condition—a key principle of design thinking. Next, you need to define a prospective solution’s functional requirements and the core competencies required to support that solution. Since the purpose of your MVP development is to limit features to those required to deliver a narrowly defined solution, you want to be sure you have a good understanding of the solution’s limited functional requirements, aligning the things you do best as a company with the needs of a solution tailored to your niche market.
  2. Share. Having defined the customer’s needs and the solution’s functional requirements, the next step is to host a meeting with all team members to share a common vision of the project. Your objective is to establish roles for each team member, with everyone understanding how they support the project and how each individual contributes to the project’s success. You want to avoid having team members merely given tasks without the context of how their tasks fit into the larger development. This approach allows team members to consider the entire project as they perform assigned tasks throughout the development, reducing the likelihood of misaligned pieces when the project is assembled as a whole.
  3. Prioritize. The third step in this process is to meet with the project’s management team to categorize features slated for particular releases. The Kano model may be helpful to organize features in categories such as “Basic,” “Performance” and “Wow.” The idea is to balance each release with features from each category, being mindful not to fill a release with features from only one category, such as having a Basic features release, or a release with only Wow features that doesn’t include a set of Basic features required to make a product viable. The outcome of this step is a plan to introduce features to the marketplace through frequent releases with incremental customer value – another key design thinking principle.
  4. Implement. The fourth step is where product releases are developed. It’s important to remain mindful that design thinking is an iterative process requiring the need for feedback and validation. As such, each implementation needs to enlighten: include mechanisms and processes that will let you examine customer experience after each release. Apply web analytics or specialized tools that provide extensive commentary to analyze customers and gather valuable feedback. It is important not only to collect data, but to make it work: make sure that the results of any feedback are added to the backlog to constantly improve your product.
  5. Validate. The fifth and last step in the process is to review feedback on a particular release, validate the vision, and begin the process all over again with step 1. This focuses each release to meet specific needs of a target customer, creating a building block approach to product development that provides incremental value at a low risk. Accept that your concept may not immediately be accepted by users. Try to be objective, don’t see things in black and white, and restructure your vision to improve your product.

If you dig deep and keep peeling the onion, big companies are gripped by a fear of decision-making. As a rule, this leads to research that in most cases only stirs up uncertainty and steals valuable time, and that is then capitalized on by more mobile competitors. Putting forward a hypothesis would be much more effective. This way you define a vector of development, creating favorable conditions for a rational plan to confirm and validate your hypothesis, rather than getting lost in a chaotic search for a solution.

To make things clear, structure your tasks: build up a framework, define both focus points and sticking points of your research, and remember that most questions have two answers—the one that appeals to business and the one that speaks to a customer.

Think like a journalist when starting a product development cycle, and ask these questions:

Who?

Who is going to use your product? What are their habits and preferences? It is very important to understand real user needs and how they are addressed now, without your product. Define the key problems and set your sights on them. What’s the context of use? What is their motivation behind using your product and how can you inspire them to make the most out of it?

Where?

Think big. What is the place of your product in the ecosystem?  Sometimes it may be just a part of a greater service. Keep in mind the environment of use since it creates a general customer experience.

When?

Whether you like it or not, time is vital for your project. “Done” is better than “perfect.” That’s why it’s important to keep the scope of your project in mind, to limit it to truly necessary things for a quick market release.

Why?

What is the real value of the product for your customer and your business? What issues does it address and in what way? Why did you create it and what’s its role in the company development?

These questions are essential for creating a general perception of the main problem: it’s so easy to get side-tracked with a load of on-demand, seemingly effortless tasks! Besides, it’s impossible to solve a problem that doesn’t exist, so why carry an extra burden? When details are pushing you to the limit, take an imaginary step back and try to see the problem from a different angle. Visualize the role of a certain detail in the general canvas of your work. It does not mean you have to bury your project under piles of documentation. We all know that red tape is more about restricting rather than making things easy, and freedom is especially important at the initial stages of any project. This is how innovation is born; under conditions of free thought, bright vision, and sheer inspiration.

Conclusions

Modern product development is moving to a design thinking approach, delivering limited feature products to target markets to satisfy immediate customer needs. This approach limits the risk of developing a product no one wants, which may be an unintended consequence of a longer, more costly development targeting a broader market with extensive features and greater corporate investment. Frequent releases based on customer feedback improve customer satisfaction and provide timely validation to the long-term vision of a product and company.

Design thinking supports a building block approach to product development where features can be cost effectively improved through frequent releases, adding or upgrading one module within a larger system. The nature of design thinking’s focus on customers and incremental releases sustains high levels of customer satisfaction through continual delivery of valued features throughout a product’s lifecycle.

About the Author

Dmytro Svarytsevych is the Design Office Director at SoftServe, Inc. He is responsible for defining and integrating a company-wide User Experience Strategy to facilitate a consistent and flexible expertise growth, as well as applying UX best practices and methodologies to SoftServe projects. Dmytro is also a contributor to the SoftServe United blog, and holds a Masters of Physics from the Ivan Franko National University of Lviv.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • You will not end up with 2 cars

    by he hy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    There is a crippling flaw in the graphics that makes it extremely difficult to defend the efficiency and accuracy derived from the hybrid Design Thinking/MVP process :

    * After 2 years of effort, you do not end up with 2 vehicles that look/function the same {as indicated by the first graphic}*

    With MVP/Design Thinking approach, you should end up with a vehicle that more closely resembles the needs of your user or else you have uncovered no additional needs that the waterfall team knew at year=0. Its more likely that the second vehicle results in building a truck!

    That said, the MVP/Design Thinking hybrid concept is spot on

  • First graphic of MVP may mislead readers

    by Greg Cohen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    although I agree with the premise of the article, I have to agree with @he hy the first graphic is an over-simplification to the point of being misleading. A skate board is not a route to a car. The purpose of MVP is to select a narrow segment of the market that can use a limited set of features and then expand your addressable market by building additional capability. What the graphic demonstrates are four entirely different solution that need to compete in four entirely different markets. We are talking different customers, different distribution channels. These are four different businesses.

    If you liked wheeled vehicles, you may want to look at Telsa that produces concept cars and the roadster to understand the technology and all the systems of a car before building a mass market vehicle.

  • Re: First graphic of MVP may mislead readers

    by Dmytro Svarytsevych,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for your comment, I cannot but agree. If to look at the matter from a different angle, the main aim of the graphic is not to make a car out of a skate board, but to show that if the main user need is transportation, then we should cover it fully on every stage - from the cheapest solution to ultimate result.

  • Re: You will not end up with 2 cars

    by Dmytro Svarytsevych,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The graphic shows two different options/processes - it doesn't presuppose applying both at the same time. Our aim is to satisfy the user needs asap. But hey, next time I'll try to visualize my thoughts in a clearer way. Thanks for your feedback!

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT