Product with a Capital P

The product is not just your app, website or whatever you’re coding. Your “Product” starts with the experience a user has the first time they see your brand somewhere. On your website, in an ad, at a tradeshow, etc. The onboarding experience of your product is also part of your Product and so is your documentation, the emails you send, your newsletter, your slide decks that your sales team uses and your customer support experience. Even uninstalling or deleting the user’s account is part of it. You want people that decide not to use your Product for whatever reason to still tell their friends about it.

Done Done Done

Implement a culture of “done done done”. The product is not done when the code is written, that’s only the first done. The other two dones are often forgotten by engineers and even product managers. They are things like documentation, launch announcement, etc. that are all part of Product.

Problem vs. Solution

I always tell people to remember that users are experts in their problems, but the company must be the expert in solutions. So you should absolutely listen to users, but you often have to nudge them to talk about the problem they’re trying to solve vs. asking for specific solutions. Most people’s default is to ask for solutions and I’ve met many PMs who don’t dig in to understand the underlying problem. Completely understand the problem before even thinking about a solution.

Then the work is to find the best solutions to the problems worth solving. You may end up shipping what users asked for, but you may also come up with a better solution that no user thought of. That’s when magic happens.

Customer Discovery

This type of user research typically involves meeting with the customer / buyer / decision maker and asking key questions related to business needs, workflow pain points, and issues with current solutions and workflows.

Goal: find 6-8 reference customers (Earlyvangelists) in parallel with discovering and developing the product.

Earlyvangelists:

  • are experiencing the problem we’re trying to solve and care deeply about it
  • are willing to partner with us
  • will spread the message

How to identify them - questions to ask them

  • Talk me through your top priorities/problems
  • Have you experienced this problem?
  • How are you solving it today?
  • How well does your current solution work?
  • (What) would you pay for something better?

Their commitment to us

  • make buyers and users available
  • frequent onsite visits
  • deploy test versions and give feedback
  • be a reference if they like the delivered product

When asking people what they want, always ask what they would give up for it or how much they would pay to find out how valuable it is for them.

📝 More on customer discovery from Marty Cagan at SVPG

Product Discovery

The inconvenient Truths about Product

  1. At least half of our ideas are not going to work
  2. The ones that do require multiple iterations to generate value for the customer

From 📝 The Inconvenient Truth About Product

Given these truths, the goal of product discovery is to find a solution that is valuable, usable, and feasible. Continuous and rapid experimentation lets us quickly identify the ideas to invest.

Opportunity Assessment

Start with this to frame the problem for discovery.

  1. What problem are we trying to solve?
  2. For whom are we solving it?
  3. How will we know that we’ve succeeded?

Four Main Questions

  1. Will they buy/use it? (valuable)
  2. Can they use it? (usable)
  3. Can we build it? (feasible)
  4. Will stakeholders support it? (feasible)

1 and 2 are usually done by validating a low fidelity prototype with a few potential customers. 3 can be answered by a (rough) engineering design doc. 4 includes conversations with all internal stakeholders.

Principles

  1. Our customers are not able to tell us what to build
  2. We must validate our ideas with actual customers
  3. The most important thing is to establish value
  4. Engineering is hard, but UX is too
  5. Functionality, design, technology, are inherently intertwined
  6. We know most of our ideas won’t work, and those that do require iteration
  7. Our goal is to validate our ideas as quickly and cheaply as possible
  8. We must validate technical feasibility in product discovery, not after
  9. We need to validate with stakeholders in product discovery, not after
  10. An MVP Test (usually prototype) is the main tool for product discovery. The smallest test we can devise to prove an idea or hypothesis. Not an actual product.

How to build and validate a prototype

  1. Use low fidelity prototypes: Invision, Keynote, wireframes, even paper+pen sketches
  2. Put someone in charge of scheduling user tests regularly (monthly, weekly)

More on prototypes

Product Strategy

User Testing

  • It’s never too early to start testing.
  • Don’t be afraid to test with a prototype that feels too rough, it may actually encourage users to comment more.
  • Don’t obsess about finding people from the target audience, you may learn something from other users.
  • Three participants are enough to find most of the problems with your prototype.

Books and articles on user testing

Beginner Users vs. Power Users

If your product involves complex automation, don’t hide it entirely. Show what’s actually happening in the product to communicate its value. Especially if you’re selling to sophisticated users, they will appreciate being able to see what’s going under the hood. If you have a mix of users that appreciate easy of use, and power users who want to pop open the hood, it may make sense to have two different interfaces. A simple one that is streamlined for the most common workflows among beginner users, and one that exposes all the knobs that power users want (often via an API).

Competition

Be aware of your competition but not afraid. If you blindly copy competitors you’re always going to be a step behind, and you don’t know which of their ideas are good or bad. Obsess about your customers instead, listen and identify their problems and solve those that other’s aren’t solving, or aren’t solving well.

A productive way to do competitive research is to read competitor forums to find out weaknesses their users are complaining about that they aren’t adressing and solve those.

My Product Manager Checklist has some useful reminders for Product Managers.