The online whiteboard of Kristofer Palmvik
"I wanted people to join a product trio because they were motivated to be part of it, they wanted to be doing discovery, they wanted to be very empathetic towards our customers."
Discovery is about the collaboration between the Product Manager, the Product Designer, and the Tech Lead to discover the right solution to build before writing any scalable code. Typically, this involves talking to end-users, customers, and stakeholders to gauge their needs and then ideating, prototyping, and validating solutions—quickly. The last word is key here.
Discovery is undoubtedly an indispensable skill for anyone working with product development. But how can you actually do that in practice?
This book features real-life stories from product development, traps and fallacies that you should avoid, mental models and frameworks to build the right product. The contents are both theoretical and practical in nature.
We collect evidence of various types and gradually build a better understanding of the idea. We start with cheaper modes of validation (assessment, data gathering, early-stage tests), and move to more expensive ones only if the idea still looks good.
Sally and Jim don’t have any customers. Nor do they have a product. But this directional goal allows them to start interviewing people who match their target customer profile
I proposed that we differentiate between what I’m calling Opportunity Space Discovery and Solution Space Discovery
I found the term "discovery" from the pharmaceutical industry for the process they used to come up with a viable medication. Unlike the software industry, the pharmaceutical industry acknowledged the risk up front.
I work with dozens of product teams around the world. In helping them to build a discovery capability — the ability to develop consumer insight— I provide this checklist
If you think you can get what you need by having product managers document PRD’s instead of product discovery, then you may as well just give up on innovation and hire Accenture.
In no particular order, these are the talks and people that have helped shape the way I think about product discovery.
Sadly, one of the most time consuming and expensive ways to learn is to build potentially shippable software. So we don’t – unless we really can’t come up with any other way to learn, or we’re really confident our bet is good.
I see the Discovery track happening in 3 different layers (or sub-tracks). In essence, they are all discovery. But each one involves tasks of different natures that requires different skills from Product Managers, Product Designers and the rest of the product team
Your product team will need to keep its work visible to stakeholders outside the team. If your product team is doing both discovery and delivery, you’ll need to review both those things. If you’re new to dual-tracking, use this recipe as a starting point.
If your team is a product team engaged in both discovery and delivery, your planning session will need to account for both kinds of work. This recipe will give you a starting point.
I see the word discovery used to describe what seems more like research. The first problem is the confusion in collaborating with people who have different definitions of the word. The second problem is a false sense of confidence when making decisions.
When Spotify does launch in the U.S., though, look for a new version of the player that adds social elements – like social playlists – to the product. That’s a big weakness Spotify has against MOG, which uses social elements to aid discovery of new music. And Spotify will also supposedly let you play songs that you have on your hard drive (like via iTunes) that they don’t have in their library. That will help fill in the ever-decreasing gaps in their library, and make Spotify that much more compelling for users.