In this article, I would like to share the learnings that I have gained from the book Inspired written by Marty Cagan on building products that people love.

Overview

We will take a look at why many products fail, what is the better approach, and the right process to build the product that users love.

Why do products fail?

Problem with product roadmaps

Most product roadmaps are the root cause of most waste and failed efforts in product organizations.

Many enterprise companies today build roadmaps, which may consist of a bunch of user stories or product features. Roadmap serves 2 purposes:

• Organizations want to ensure that their teams are working on high-value works.
• In order to run a business, organizations need to be able to plan to determine dependencies and figure out how various departments can work together to meet the business objectives.

Marty explained that the intention of the roadmaps is good, but they are ineffective to create great products. Reasons being:

• Most of the initial product ideas do not work.
• Second, if the ideas do work, typically it takes a few iterations (time to money) to reach the point where it delivers value for both the users and the business.

The alternative to roadmaps

Marty suggested that instead of telling what the product teams should build, business context should be communicated clearly to the teams. The business context consists of 2 key components:

• Product vision and strategy that describes the direction (vision) that the organization is heading, and the pathways to get there (strategy).
• Business objectives that describe the specific business objectives for each product team — possibly in the form of OKR (objectives and key results).

By communicating the business context to the team instead of giving them a list of product features:

• The product teams are held accountable and have the freedom to solve the problem as they see fit. Instead of mercenaries, they become missionaries.
• As mentioned, most initial ideas don’t work, giving space and time to the team to find the best solutions ensures that the business problems get solved, shifting the focus from output to outcome.

The right process

We have found a better alternative to roadmaps, the next question is, how should the product team go about finding the best solution? Enter product discovery.

Product discovery

The purpose of product discovery is to address the following critical risks:

• Value risk — Will the customers choose and use our product?
• Usability risk — Do the users know how to use our product?
• Feasibility risk — Can we build the product?
• Business viability risk — Does the solution works for our business?

The goal of the discovery is about the need for speed, to try out many ideas, and find the best fit. Ultimately, we want to launch the products and new features confidently.

There are multiple key techniques in the framework (I will not go into the how-tos, but rather focusing on what the techniques are about and the underlying principles):

Framing techniques

Framing helps the team to align on the purpose, business objectives, and problem to focus on, and more importantly to identify key risks. The key questions to answer here are:

• What business objective do we intend to address (objective)?
• How will we know if we have succeeded (key results)?
• What problem will this solve for our customers (customers problem)?
• What type of customers are we focused on (target market)?

Techniques: Opportunity assessment technique, customer letter technique, start-up canvas.

User research techniques

User research is extremely important in a design process, it helps us to place people at the center of our products and validate the questions and assumptions that we have in the previous step. By talking to users we will find answers to:

• Are our customers who we think they are?
• Do they really have the problems that we think they have?
• How does the customer solve the problem today?

Techniques: User interviews, concierge test, the power of customer misbehavior

Planning techniques

Once we have understood our users. Planning techniques provide structure to the teams as to how they should go about figuring out the solutions.

Techniques: User story map, customer discovery program

Sidenote: I personally had tried the user story map approach, basically the customer journey is broken down into granular user stories. It (i) provides structures and reduces fuzziness which is common at the start of the design thinking process, (ii) helps the product team to focus on desired user outcomes.

Prototyping and testing techniques

At this stage, the product team builds prototypes to evaluate and test the design solution to further refined it.

The purpose of the prototype is to learn something at a much lower cost in terms of time and effort. Building a prototype also helps the product team to discover substantial issues upfront, for instance, scenarios and gaps in user flows.

Most importantly, testing the prototype with the users helps us to address value (desirability) and usability risks (usability).

There are different types of prototypes:

• User prototypes — These are the most common ones. The prototype looks and feels like the real thing, it is often used for communicating the design to stakeholders and conducting usability tests.
• Feasibility prototypes — These prototypes are built by the engineer to address technical feasibility, for instance, when trying out new technology or algorithm.
• Live-data prototypes— These prototypes collect actual data to prove a hypothesis, determining whether a feature, approach, and workflow really work.

Measuring results

Finally, Marty emphasized that the product team must measure the results. Pearson’s law states that “when performance is measured, performance improves; when performance is measured and reported back, the rate of improvement accelerates.”

Closing note

Overall, I appreciated the book’s focus on product development, it has broadened my views on the product development process and the critical aspects that are missing in many large organizations.

Some key takeaways:

• Fall in love with the problem and not the solution, the first ideas don’t work most of the time.
• As a designer, it is crucial to gain clarity on the business objectives. Oftentimes, as a designer, we don’t really take on the business lens. Perhaps, it’s time to step up the game to close the gap between business and design. I do believe that being able to speak the same language with the stakeholders helps us to fight for our users better, albeit challenging.
• Involve the developer in the design process to address feasibility risk. Get ideas from developers, they may offer a more efficient solution to solve a problem from the technical standpoint.
• Focus on the outcome, not output.
• As a designer, how might we be passionate about the problem and get the client to get excited about the vision, to achieve the best outcome together?