INSPIRED

To enhance our discovery process, we can engage a group of reference customers to work with us.

They are our beta testers and subject matters experts. If we can make them really happy, then we probably can make the broad market happy.

Not only they are decent beta-testers, but after we launch the product, we’ll already have a group of users who can advocate for us and refer us.

Good reference customers are those who:

• are our target,
• have a problem our product solves,
• are not obsessed with technology,
• have time and willingness to help us.

It’s important not to ask them to pay for the product or pay them for being part of the group - it builds a slightly different relationship. Treat them like colleagues - we need each other equally.

We need a team of missionaries - people on a mission to solve problems and make people’s lives better, not a group of mercenaries - people paid to deliver features.

A key aspect of building such a team is product evangelism. It’s “selling the dream” - helping people imagine the future and inspiring them to help create that future. To sell the dream, we should:

• Use prototypes. So it's easier to see the big picture.
• Share the customer's pain. Bring the team along for customer visits and meetings.
• Share the vision. Make sure the team understands the product vision, strategy, and principles. Show how their work contributes to this vision.
• Share learnings. All the time, both good and bad.
• Share the credit. Make sure the team views the product as their product and feels appreciated for growing it.
• Learn how to give an excellent presentation. Whether a product demo, VC pitch or sprint planning, presenting is an opportunity to inspire the team.
• Be an expert. We must be a go-to person when it comes to understanding the market, competitors, users and customers. That’s how we build credibility and trust.
• Show excitement and enthusiasm. It’s contagious.
• Spend casual time with the team. A team that bonds well together works well together.

It’s sometimes hard to explain what ‘discovery’ really is. Marty gives it an interesting perspective - the ultimate goal of product discovery is to de-risk by getting a positive answer to the following questions:

• Value. Do customers need it? Will they pay for it?
• Usability. Will our customers know how to use it?
• Viability. Will this work with our business model? Can we profit from it?
• Feasibility. Can we implement it within assumed constraints?

While delivery is about creating the solution, discovery is about de-risking the solution.

There are four fundamental areas a good PM must be knowledgeable about

• Customer - understanding who is the customer, what they want and why the buy
• Data - understanding of data around the product.
• Company - knowing what’s going on in all areas of the company.
• Industry - knowing competitors and the landscape of the industry.

Testing value on interviews is tricky - people are generally trying to be nice. Look for proof of value:

• Proof of money: will you pay me now?
• Proof of reputation: will you share on social media? Will you input your boss’s email with a recommendation?
• Proof of time: will you invest time to work with me on it?

Building product culture in a company is hard. Tactics to get started:

• Discovery sprints: Engage the team for a few days and let them explore a solution for a big problem. If the team hasn’t done much discovery up to this point, focus on learning the process.
• Pilot teams: They allow us to build new, healthy habits step by step.
• Internal hack days: They motivate the whole company, improve morale and drive momentum for the larger mission.

Questions for assessing opportunities:

• What problem will this solve?  
• Who are we solving the problem for? How big is that market?
• What alternatives do competitors provide, and why we are the ones that can succeed?
• What factors are critical to success?
• What metrics will we use to measure our success?
• Why is this the right time to enter the market? What would be our go-to-market strategy?
• Based on the above questions, is this an opportunity we should pursue?

‍

• PM should clue designers in on everything they are doing. For any test, research, assumption, risk tackled - the designer should always be up-to-date on what’s on PM’s plate.
• At least half of the product ideas are bound to fail. And those ideas that don’t fail rarely are complete after the first try.
• The importance of visual designers is often underestimated. Their work has the power to evoke powerful emotions in customers. Products that can evoke strong emotions are usually hot.
• Feasibility risk is not only about ‘can we do it?’, but about ‘what is the most efficient way and how long will it take?’. Neglecting feasibility assessment is one of the main reasons teams fail at estimating effort.
• Building product culture in a company is hard. Tactics to get started:
• The design team should have enough capacity to experiment with multiple designs before the engineering process start; working one sprint ahead might not be enough.
• Set aside 2-3 hours every week to have some casual 1:1s with key stakeholders to build relationships, get a buy-in, elicit feedback and establish so-needed trust.
• We must provide visibility into what we are working on to build credibility with management.
• The role of a true leader is to provide vision, strategy, objectives and coaching - not delivering a list of features to implement.
• Teams should share lessons with one another, but not depend on each other. We need a mixture of collaboration and autonomy.
• Working backwards - customer letter. We write a letter from a customer telling us how satisfied the customer is. What do they like? What problem does our product solve? Then we can work backwards from that letter.
• Working backwards - CEO letter. Similar to a customer letter, but this time from a CEO perspective. How did the product help the company? What business impact did it make? It allows us not to lose sight of a business perspective.
• Product principles are a great extension of product strategy. They give clear direction to the team and allow product teams to make autonomous decisions based on them.