Product Discovery

Overview

Product Discovery is a term for working very quickly to discover a product or feature as you work on it, with feedback from users, in an area of significant uncertainty. The process described here works best when innovating in a somewhat well-known space. e.g. adding a new feature into an existing product.

When doing product discovery, don’t start with a plan for the entire sprint. Plan enough for the first iteration with a goal of finishing within 1-2 days. Then ask “what’s the next most important thing”, and work on that for an iteration. Ideally, do 5 iterations a week, with each one needing a little planning.

Start with some brainstorming on what could be done without regard to time (call this “Think Big”), then narrow down to what the most important thing is to deliver in 24-48 hours (call this “Think Small”). Then work on that, as a team, and deliver the first version within 1-2 days. Then see how it feels, and decide what the next most important thing to work on is, and iterate. Then iterate again. And again. At some point, have external users take a look for validation, and add some metrics for tracking success. By the time you’re done, you’ve got a beautiful, polished, and valuable project finished and validated.

The thinking big part is great to get people out of local optima and think about the big picture. Context swap everything you can on the subject in a short period of time. Go crazy with ideas. Then narrow that down to the core of the feature. What’s the one thing you can deliver that would satisfy the goal without all the fluff. Sometimes it’s surprising what turns out to be the main point and what we can get away without.

Example Week

Example Week

Details

Process

1 week sprints. Planning is 2 hours. Standups are daily and walk-the-board style rather than yesterday/today/blockers style.

Pre-Plan

PM and Eng Management get together at the end of the previous sprint to gain a better understanding of priorities so we can go into the sprint better prepared for planning with the team.

Retrospective

Retrospective is about meta — it’s not a status update on the last day or even the last week of work. It’s about what went well, what didn’t, and most importantly what would we do differently or what can we learn from it. Sometimes we can’t do anything more than surface a problem with no immediate solution. Retrospective should aim to be only 15-20 minutes with a hard-stop at 25 minutes. If something really deserves more time, perhaps it should be a separate meeting (with less/more/different people).

Prioritize and allocate

Decide on project/product/feature to work on (and who will work on it, if there’s more than one project ongoing, which shouldn’t happen very often).

Think big and think small

  • Expand feature - what can it be.
  • Shrink feature to something achievable in 24-48 hours - cut scope to the minimum to make it functional and shippable.
  • Define metrics to watch and define what success looks like.

I’ve heard that Google and maybe Apple do some kind of expand and contract phases, although I think one of them expands on a Friday and then contracts on a Monday. Anyway, it’s a powerful tool.

Development

  1. Deliver iteration of the product/feature.
  2. Test with ourselves, coworkers, and users.
  3. Decide on and implement the most important improvements, whether they are functional, UI, or UX.
  4. Repeat.

The first iteration should take 24-48 hours, with the rest taking 4-8 hours, for a total of 5 iterations in a week. 7 iterations if you’re awesome.

Delivery

  1. Deploy
  2. Measure success of product/feature with real customers (private beta, public beta, or GA)

Sometimes you can expand from internal alpha to private beta to public beta within a single sprint. Sometimes you can only get to one stage within a week and you increase scope in subsequent sprints. The important thing is to always aim for learning as quickly as possible. If internal users are still providing surprising feedback, and you’re learning from it, then that’s still valuable.

Sprint Philosophy

  • Premature optimization is the root of all evil
    • Seriously, read Lean Startup. Putting any time in something that is later going to be thrown away because it turned out to be the wrong thing is the worst efficiency possible. Do just enough to validate. Focus on your biggest risks first.
  • How does this benefit the developer (user/customer)?
    • This doesn’t mean the customer is always right, or that we’re not allowed to think for ourselves, but that we should always make sure the user is represented in the discussion. Don’t talk (only) about internal or engineering benefits. Make sure it’s going to be of benefit to the end-developer.
  • Always work on what’s most important right now
    • Sometimes breadth-first beats depth-first. If customers are having a horrible experience with documentation, how can we say another iteration of notifications is more important?
    • But timing matters too — if we just finished an iteration on something, there’s value in leveraging that momentum (reducing context switch, etc.).
    • But don’t forget that we learn more about a feature as it’s being used, so letting something be out in customers’ hands for a while might result in better insights into the next most important thing rather than just theories in our heads.
  • Work on one project at a time
    • It’s important for the whole team to work on the same project. It doesn’t have to be the same feature, but it should be the same space. It sucks if one developer is working on something completely unrelated, or design is working on the next project ahead of engineering.
  • Work on one project a week
    • It’s important to plan a single project for an entire (week) sprint. Finishing one project on Wednesday then starting a new one on Thursday rarely works, at least for product discovery work.
  • Always finish sprints cleanly.
    • Don’t let WIP spill over the weekend. Saying “I’ll finish it on Saturday” rarely works, and even if it does, it can’t be peer reviewed and shipped until Monday and then it’s impacting the next sprint. This isn’t about working overtime. It’s more important to ask what scope can be cut so you still deliver on time. If you really want to code on your weekends, pick up something new for fun.
  • Collaborate and communicate
    • Communicate throughout the day, not just at standup.
    • Eliminate blockers — Tight loop always wins. When a decision needs to be made, get the relevant people together and make the decision - 5 minutes or less.
    • Roles (PM, Designer, Engineer) should only be used to resolve tie-breakers. Everyone’s opinions should be valued regardless of origin. The entire team owns the solution. Nothing is more powerful than ownership.
  • Iterations FTW, Refactors FTW
    • Everything is an experiment. Start with a hypothesis.
    • Iteration is better than perfection - But actually iterate; iterating once is called doing a half-assed job. It’s OK to ship things that aren’t perfect.
    • It doesn’t count until it ships. (Ship in this case can mean the point where you can learn something.)
    • Don’t be afraid to take time to refactor.
  • Design is about understanding and solving problems, not just the looks
    • Designers work in code whenever possible, using Sketch/Photoshop when necessary.