Photo by Alex Kislow (https://www.flickr.com/photos/corpz/5634268846/)

Building Products

I recently gave a talk at TNW Europe about a framework we use at Facebook to help us focus our product development process. Working on that talk got me thinking about the many other lessons I’ve internalized over the years about what it takes to build great products.

This list is not complete nor certain. If there were some perfect step-by-step instruction manual out there (Step 1: Start with inspiration. Step 2: ??? Step 3: Profit!), then we’d shell out good money for it and then pat ourselves on the back while watching amazing new products bloom around us like flowers fields in May.

The journey is 1% finished. Let’s keep trekking and learning.

On Framing

1. A product succeeds because it solves a problem for people. This sounds very basic, but it is the single most important thing to understand about building good products.
2. The first step in building something new is understanding what problem you want to solve, and for whom. This should be crystal clear before you start thinking about any solutions.
3. The second question you should ask yourself is “why is this particular problem worth solving?”
4. If the audience you are building for is narrowly defined (and one that you are a part of), then you may be able to rely on your intuition to guide your product decision-making. If not, then you should rely on research and data to inform your decisions.
5. If you are a start-up founder, your path will be easier if you go after a problem for a narrowly-defined audience, and then expand to broader audiences after you have some initial traction.
6. The problem you’re trying to solve should be easy to communicate in a sentence or two and resonate with someone from your target audience. If not, consider that a big red flag.

Execution

1. Good execution is about getting to believable conclusions in the shortest amount of time possible.
2. Bad execution is when you try something that fails and a) you can’t really draw lessons out of that failure that would apply to a future project (because you don’t know why it failed) or b) it took you a year to learn a particular lesson when a smarter path would have let you learn the same thing in 3 months.
3. What typically separates successful and unsuccessful teams is not whether they do things that fail (this is guaranteed), but how well they can consistently execute.
4. When exploring solutions for a particular problem, go broad before going deep. Brainstorm 10, 20, 50 solutions for the problem before getting into the mindset of picking a “winner”. The first 5 ideas will be the obvious ones. Creativity happens when you start to explore the 11th, 20th, or 50th idea.
5. If you’re presenting a product plan and someone asks “have you considered trying X instead?” and your answer is “No,” that is a red flag that your exploration process was not rigorous enough.
6. Use empirical evidence to help you narrow down the best idea(s) out of the ones you brainstormed. (For instance, pick the top N favorites from the team, design or prototype those out in higher fidelity, and put them in front of people to gauge their reactions).
7. Once you’ve figured out the particular solution you want to execute towards, frame it in terms of a hypothesis — what are you assuming will happen if you build this? (e.g. “The problem we want to solve is ensuring that every city resident knows what local events are going on every weekend. Our hypotheses is that we can reach X% of residents through an e-mail digest.”)
8. You should constantly be looking for ways to short-circuit vetting your hypothesis. Can you run your idea by some people on the street and see if it’s understandable? Can you run a survey targeted to your audience and gauge whether enough people are interested enough in the idea? Can you quickly build a version that gets you a clear conclusion, even if it’s not as complete as the vision you have in your head?
9. Once you have clear indication of positive signal on your hypothesis, don’t assume you need to rush to ship whatever you tested right away (as you may have taken some shortcuts to get a signal faster.) Instead, make a separate, intentional decision about what the bar is for full launch when it comes to polish and additional functionality. What’s acceptable to test and what’s acceptable to ship broadly should have different criteria.
10. If you’re embarking on a big project involving a lot of different changes, see if you can split up the changes into smaller, independently testable milestones. Don’t fall into the trap where you make five changes, get a bad result, and now have to figure out which change(s) were responsible.
11. Do a team post-mortem after every project, regardless of success or failure. What product lessons did you take away? What team lessons? What would you do differently in the future? Then, share these learnings with the whole company.

Measuring success

1. How you measure success is critical to the long-term results of your team because it’s the thing that people rally around. Make sure to give this exercise the proper time and attention (more, even, than you would give to thinking about “how should we do this?”).
2. Define what success metrics look like for your product before you launch. Otherwise, if you try to interpret results after they start coming in, confirmation bias will lead to a non-objective reading.
3. For each success metric, come up with a good counter metric that would convince you that you’re not simply plugging one hole with another. (For example, a common counter metric for measuring an increase in production is also measuring the quality of each thing produced.)
4. If an important metric moves unexpectedly, whether positively or negatively, your first question should be “why?” Don’t try to develop strategies to boost/counteract what’s going on before you fully understand the why.
5. Use the Crystal Ball technique to help you pick the right ways to measure success. Ask yourself “If I could know anything in the world about how people are using my product, what would I want to know to in order to tell me whether or not my product was successful?” (Typically the answer people come up with is not #of clicks on a button but something more abstract like How many people who used my product received value from it?) From that answer, work backwards to get to a measurable metric that best approximates what you’re trying to get at.
6. Your goals should always be set with the best information you currently have. If you were working towards a predefined goal and then discover new information that changes your understanding of the world, consider whether you should adjust your goals based on that new information.
7. If you work on a team where you don’t understand or agree with how the team measures success, bring that up right away. It’s better to hash through these things earlier rather than later given how fundamental this alignment is to productivity and good execution.
8. If you find yourself constantly getting into debates with your teammates about product direction, the root cause is probably a disagreement in the way you’re measuring success. See if you can articulate your concerns in the form of a new proposal to measure success.
9. If you are trying to figure out whether your product has product-market fit (versus trying to optimize or scale), you’re better off goaling on retention (how many people use your product and then love it enough to come back?) rather than on engagement or # of users.

Team Dynamics

1. Thinking in terms of your role (what’s expected of a designer? What’s expected of an engineer?) will cap your ability to have impact. Instead, think in terms of “What can I do that will most help my team be successful?”
2. Teams that fall in love with a problem have more successful outcomes than teams that fall in love with particular solutions. This is because knowing that a problem is worth solving continues to be motivating even when a team doesn’t come across the right solution on the first, second, or Nth try.
3. Always assume best intentions. I mean, at the end of the day, everyone wants the same thing — to build something great. You might be wrong some small % of the time, but you’ll still be saving yourself a great deal of unnecessary drama.
4. Understand what you’re uniquely good at, and what your teammates are uniquely good at. Then, divvy up team responsibilities in a way that acknowledges those strengths.
5. Good communication is the key to a healthy team. Every member of the team should feel like they can safely express their viewpoints, even if those views are contrarian. Diversity of opinions is how you get the best results. So don’t be afraid to express your view, don’t be afraid to repeat them if you’re not sure people heard or understood you fully, and strive to create that safety for others.

Interested in asking a question or following along for more advice? Sign up for my weekly letter.

Related past articles on building products:

• How to do a Product Critique
• The Two Ways of Building
• How to work with Designers
• Build a Product with a High-Concept Problem
• The Tax of New
• The Agony and Ecstasy of Building with Data
• Metrics, a Story