Product Discovery Principles

“The most important thing is to now what you can’t know.”
Marc Andreessen

1) We know we can’t count on our customers to tell us what to build

Avoid focus groups. Customers don’t tell you what to build because they simply don’t know what is possible with latest technologies in place. Furthermore, they don’t know what they actually want until they see it – hence use prototypes during your customer feedback sessions. Customer-facing product teams go 3 hours per week to see the customers. “Customer inspired – customer enabled”.

The iPhone wouldn’t happen with focus groups. Skype hired Nokia, Motorola and Apple people and they compared the different approaches to innovative products. It took 3 ½ years to build the iPhone. Nokia and Motorola were doing focus groups when Apple started the iPhone. Palm has just released the Treo with Touch Screen and people didn’t like it. The focus group gave clear indication to skip the touch screen. So, at the time, Motorola and Nokia decided not to build phones based on touch screens. Apple hat a vision – the iPhone vision – “Build a touch screen powered phone.”

2) The most important thing is to establish value

Value for customers, creating value for customers. Typical product roadmaps line up features. The underlying assumption of feature roadmaps is that there’s value in the feature and business viability is granted. But that is typically not true.

3) We recognize that engineering is hard, but the user experience is often even more difficult, and more critical to success

This is especially true at B2C companies – 50 engineers and 2 visual designers don’t work out. The experience and value perceptions created at the customer is vital – UX is more critical to success than technology.

4) We recognize that functionality, design, and technology are inherently intertwined

5) We expect that most of our ideas won’t work, and those that do will require several iterations.

Many iterations never make it beyond us – the team; they’re simply stopped internally in early stages.

How many iterations should one follow before skipping the idea?

Depends on the importance of task
Ask yourself: “Are you still learning with every iteration?”
Change the approach to the problem (e.g. churn)
Timebox: 2 days for one approach

Avoid the “fall-in-love”-pitfall with design: use less than 2 days for design before result is shown to users.

Example: Ceramic class separated into two groups with separate goals. The first group should build one high quality pot. The other group is instructed to build as many pots as possible – it’s only the weight that counts. The second group won the quality challenge because of practice! The first group wanted to produce the “perfect” pot but failed with just 1 mediocre pot.

6) We must validate our ideas with actual customers

Go out of the building, talk to real customers. It’s valuable to start with your team mates, colleagues, people working inside your company – but finally, you need to get the opinion of your real customers.

7) We validate our ideas as quickly and cheaply as possible

Possible even in hardware: 15 iterations per week. Google Glass team build an engagement model prototype and improvised a futuristic user interface with simple technologies. They quickly learned about a key problem: shoulder sourness and skipped the key assumption for success.

8) We use both quantitative and qualitative techniques

Quantitative: What’s happening?

Qualitative: Why is it happening?

Example: Etsy switched to endless scrolling from pagination. The A/B-Test showed people buying less. The qualitative analysis showed: there were simply too many cool things to buy and people couldn’t decide – paradox of choice

9) We must validate both technical feasibility and business viability in product discovery, not after

Include engineers ways before planning. They need to be involved and see what to build before sprint planning.

10) It’s all about shared learning

Shared learning happens all the time in a co-located team. Discussions over coffee, exchange of opinions at the work-desk, discussions are all around. Furthermore, allow engineers 30 minutes playtime with the prototypes each day to let them express their concerns and start having good ideas on how this could be build.

With a distributed team in place, schedule a 30 minutes meeting every day to allow the exchange of ideas, to give engineers air time with the prototype and help them understand the ideas behind.

Big companies run innovation labs for product discovery. But good ideas never materialize due to the separation of Discovery and Delivery.

This blog post is part of a series. It summarizes my personal notes of the workshop held by Marty Cagan “How to Create Tech Products Customers Love” from 5th to 6th of June in 2019 in San Francisco.

One thought on “Product Discovery Principles – notes on “How to Create Tech Products Customers Love” – #9/11”

Pingback: Product Development Process - notes on "How to Create Tech Products Customers Love" - #8/11

… talking about agile leadership and technology

Product Discovery Principles – notes on “How to Create Tech Products Customers Love” – #9/11