1. Introduction

Recently I read Inspired by Marty Cagan. Inspired is a well-known book on building products. With many years of working at eBay, HP, and Netscape, Marty got heaps of experience in software development, product marketing, UX Design, Testing, and Management.

This book shares his knowledge and gives insights on how the best companies create Innovation. The focus is on technology-powered products of companies like Google, Facebook, and Netflix.

Currently working on building a career in software engineering myself, it was the perfect fit for me. With over 23,000 ratings and an average of 4.24 out of 5 stars on Goodreads, it raised my interest.

I will share my takeaways while focusing on product discovery and delivery principles and techniques. It is not a book summary, but more an extraction of what was of most interest at the time of reading.

2. Continuous Discovery and Delivery

To bring a product successfully to market we need to come up with a solution to the right problem.

The process goes as follows:

Product development can be structured into two main activities. We need to figure out the right product and then we must build the product right. That should be the mantra of product development.

Let’s get started by taking a brief overview of those four phases. Framing and planning are part of discovery, while ideation and prototyping are elements of delivery.

3. Discovery

The goal of product discovery is to reduce the risk of waste by increasing confidence in our ideas. We want to repeatably test hypotheses with cheap experiments. The output of product discovery can be a new product idea or a prioritized feature list.

A successful piece of software adds value to the world and can be used with ease. Furthermore, it should be reasonable to build and work in our business context.

3.1 Framing

First, we frame the problem by opening our view. This first stage follows the idea of divergent thinking. By adopting the beginner mindset, we keep our minds open and don't jump to assumptions too quickly. That way we make sure to dive into the problem. Taking time to explore increases the chance of creating real value.

Discovery framing techniques help identify underlying issues and help build an understanding of the problem.

Writing a customer letter or press release is a technique widely used at Amazon. The idea here is to change the perspective into a happy, satisfied user of the freshly released product. What does the customer love about the product? Why does it add value? How does it change or improve their life? With this backward approach, you see the product through the eyes of the customer. A good exercise for customer-centric design and nailing down the key value proposition.

For smaller projects, you can work with a startup canvas technique or use the opportunity assessment technique. The idea is straightforward—just answer these four questions:

1. What business objective is this work intended to address? (Objective)
2. How will you know if you’ve succeeded? (Key result)
3. What problem will this solve for our customers? (Customer problem)
4. What type of customer are we focused on? (Target market)

3.2 Planning

After exploring the problem space, we can dive into the second stage. Planning narrows the view again. We now converge our thinking to extract the root cause of the problem.

For doing proper planning, the book suggests the user story mapping technique. Writing user stories is a practice in software engineering that helps to specify the requirements of software. By using the format:

"As a <role> I can <capability>, so that <receive benefit>"

you can ensure that the product adds value.

The story map is a collection of requirements that gives the big picture of the user experience. First lay out the key activities that the user will undertake. Then break it down into user stories, that can be subdivided into sub-tasks. This simple process helps prioritize the work and prevents feature creep. Another big point is how great it works with sprint planning and versioning. I will likely dive deep into user story mapping and sprint planning within the near future. For now, I recommend Lucidchart’s article.

Another technique for large-scale projects is the customer discovery program. I will not go into this technique any further. It's good to know that it exists. Feel free to search for it on the Internet if you are interested.

With the problem laid out, we can now develop the right product. Before we jump to the delivery phase, I will give you a little example to get a better understanding of the interplay between discovery and delivery:

By determining our customer needs, we can generate the most suited solution for the need/problem. The opposite approach would be jumping straight to conclusions and building the motorbike. Even if we built the motorbike properly, we wouldn’t satisfy the customer’s needs because the motorbike is not the right product in the first place.

Finding out, that our customer needs a car and not a motorbike is discovery.

Finding out about the best way of building a car ist delivery.

By doing some proper research we can make sure, or at least increase the chance, that we have understood the customer's needs correctly. With that foundation, we can leave the discovery phase and shift our focus on how to build the product right.

4. Delivery

The purpose of delivery is to generate as many solution approaches as possible (ideation) and then to test them efficiently with the help of prototypes.

4.1 Ideation

We start by looking up existing solutions and brainstorming different approaches to the problem. We broaden our view and look around for possible solutions. The aim is to generate as many solutions as possible.

Common techniques are customer interviews and concierge tests. The customer interview technique is exactly what it sounds like – talk to potential customers. How do they currently solve the problem, what are the hurdles, and how could existing solutions be improved? Is the customer who you think they are, and what would be required for them to use your solution?

Getting out to the customer and doing their work for a day or two—that’s the idea of the concierge test technique. Looking for ways to optimize the existing solutions. A programmer's strength is to optimize processes, and you know best what is possible from a technical point of view.

"If I had asked people what they wanted, they would have said faster horses" — Albert Einstein (or was it Henry Ford?).

4.2 Prototyping

Prototyping helps to evaluate assumptions and assess risks. You want to learn something while spending significantly fewer resources than building the final product. Prototypes are built to simulate properties and behavior with simple tools.

Solution and prototyping techniques can have different degrees of realism. Wireframes, for example, can be sketched out on paper within minutes to discuss the logic and architecture of software. High-fidelity prototypes like mock-ups can render out the design just like the finished software. I use Figma for wireframing and mock-ups.

The art of prototyping is finding the right technique to test value, usability, feasibility, and business viability risk. Of most importance is to find out right away if our product adds value to the customer’s life. Will the customer buy the product? Does the product give the customer more value than what we must charge for it?

Always prioritize value over usability and tackle feasibility and viability once you have a product-market fit.

5. Conclusion

This is my brief attempt to summarize what I have learned from the book Inspired.

I may have mixed things up here and there. One of my most important learnings is the realization that terms and concepts are interchangeable. This takes away a lot of confusion and stress. I have labeled the phases as in the book with the keywords Framing, Planning, Ideation, and Prototyping. Other models of product development and design thinking use different terms.

The smallest common ground is the double diamond of divergent and convergent thinking with the aim of not only building the product right but also finding the right product. We need to figure out the right product and then we must build the product right.