Product Management in 10 Lessons

We recently hired an English teacher to help us build out Arno. She has a ton of experience teaching English, but she’s never worked at a tech startup. I put together this guide to help her be more effective when working with Makoto and me.

What is “product management”?

Product management is the art of figuring out what a team should build. One of the core startup roles is the Product Manager. It is their job to talk with different stakeholders like users, salespeople, engineers, data scientists, designers, executives, and other product managers to understand the constraints, opportunities, risks, potential business value, the market, etc. that they’re faced with. With all this information, they then build out the roadmap for what their team will build.

However, at small companies like Arno, “product management” is something that we all do together!

I worked on product teams at big and small companies, and I’ve spent the last 2 years building Arno. Let me share what I’ve learned about product management that I think could help you.

Lesson #1: It’s easy to imagine the ideal. It’s much harder to figure out the intermediate steps.

When thinking about what we could build, it’s quite easy to imagine the fully-featured version with all the bells and whistles. As a result, it’s always tempting to scope out a whole bunch of stuff and ask the developers to just build it.

This is dangerous because we are often wrong 🙂 It’s impossible to predict with 100% accuracy how users will respond once they actually use the thing. This is why at a startup you have to optimize for shipping fast so that you can allow people to use it and give you feedback.

After forming your vision for the ideal feature, you have to figure out the intermediate steps that will get you there. These intermediate steps should be versions of the feature that you can ship and allow users to actually use. Figuring out these incremental steps toward a larger vision is most of the art of product management in fast-moving startups.

Lesson #2: Think in experiments.

Every experiment tests some hypothesis. Underlying any new feature is some hypothesis about what users want. In other words, why are users going to use whatever you build? Your hypotheses should always be specific and clear because they should be your guide. For example, if you’re going to build a search feature inside your app, you have the hypothesis that users want to find specific things. But that’s vague. What things do they want exactly? Why do they want those things? By getting more specific and clear about your hypotheses, you can better decide which features your users will find valuable. Often, you will find that your initial solution isn’t the most promising one.

Once you have a strong hypothesis, you have to test it through an experiment. In order to run effective experiments, you have to measure the results of your changes. Before launching a new feature, you need to establish how you will collect the data you need to determine whether your hypothesis is valid or invalid. This data can be quantitative or qualitative.

Lesson #3: Think hard about the cheapest V1.

If hypotheses underlying the new features you want to ship are clear, then you can think hard about the easiest way to test them. For example, let’s say we have the hypothesis that users really want grammar exercises. Instead of building them out, we could just add the button to Arno and see how many people click on it compared to the other buttons 🙂

Time is a startup’s most valuable resource. Shipping cheap V1s allows us to test our hypotheses quickly and figure out if we’re wrong without wasting a lot of time.

So much of product management is just paring down the requirements of a new feature. Eric Ries, the godfather of this whole “lean” methodology to startups says, that for your V1 (or your “Minimum Viable Product”, MVP, as he calls it), you should cut your list of requirements in half and then cut it in half again. The point is that you likely need a lot less in your V1 than you think you do. Cut things out. Be ruthless. Having small V1s allows you to test a lot more ideas more quickly, which means you can more confidently invest in features that you believe will make an impact.

Lesson #4: Users, users, users.

The success of a startup hinges on making something people want. If you can do that, you have a good shot at succeeding. But if you don’t do this, you will certainly fail. Deep knowledge of users is the most valuable asset at a startup.

Finding this post helpful? Subscribe to get future ones delivered right to you.

Subscribed

Lesson #5: Focus on problems, not solutions.

You should spend a lot more time trying to understand the problems your users experience than you do thinking about how to solve them. Thinking of solutions is creative, fun, and easy. Understanding user problems is harder, more confusing, and requires time-consuming things like user interviews and watching user sessions.

But once you understand a user’s problems very well, usually the solutions present themselves.

For example, the first version of Arno was aimed at helping busy professionals perfect their English. However, as we dug into this problem, we discovered that it wasn’t a very acute one. Once people had “good enough” English, they weren’t motivated to make it perfect because it wasn’t necessary. However, through user interviews, we learned that there was a specific time when people had to improve their English: When they needed to get a certain score on an English proficiency test for university admissions. The solution was obvious: We needed to pivot Arno to focus on English proficiency tests.

Lesson #6: Experience the problem you are solving.

In startups, “dogfooding” is the idea that you use your own product. (The name comes from a dogfood commercial in which the owner of the company showed how he fed his own dogs the products that they made.) If you use your own product, you will make sure that the product solves real problems — your problems.

However, it’s not always possible to experience the problem you are solving. Arno is an example of this. It helps people learn English, but we already know English. We struggled with this inability to dogfood for a long time, but then we found a very effective way to experience our users’ problems secondhand. We created a program in which we tutor students one-on-one and — here’s the key bit — we guarantee that they get the score that they need. If they don’t, they get a refund. This score increase guarantee puts us under tremendous pressure to figure out what a student needs to improve.

If you can’t use your own product, try to enter into a partnership with users in which you’re not paid unless they succeed. This will force you to understand their problems and make sure your solution actually delivers value for them.

Lesson #7: You should say “No” a lot more than you say “Yes”.

There are always going to be way more great ideas than you have the resources to pursue. Saying “Yes” feels nice because then no one’s ideas get turned down. Saying “Yes” means you don’t have to do the hard thing of trying to figure out what will be the most impactful feature and make a tough judgement call. Saying “Yes” means you can hedge your bets and not risk the embarrassment of committing to one idea that doesn’t work out. The issue is that if you say “yes” too much, your team will be stretched too thin; you will struggle to deliver on time; and you will end up not thinking deeply enough to ship excellent features.

In product management, you have to get used to saying “No” to way more ideas than you get to say “Yes” to. This allows your team to focus and execute at a high level. You have to learn how to evaluate your options rigorously but also how to trust your gut. You have to learn how to admit when you made the wrong decision and learn from it. You have to learn how to communicate effectively with the rest of your team so that they don’t get discouraged when their ideas don’t make it onto the roadmap.

Lesson #8: Complexity is the enemy.

This is another reason saying “yes” too much is problematic. Complexity results in half measures and compromises. For example, if you are trying to decide how to design your pricing and packaging and you decide to go with both a time-based subscription model and a usage-based, pay-as-you-go model, you just created a lot of complexity to manage. You will have to implement different systems to track usage and handle billing. And what if people want to switch from one to another? Now you have to deal with customer support tickets.

Complexity is also problematic for users. People are very busy. They don’t have time to think through the intricacies of your pricing and packaging or of your product itself. They are paying you to solve a problem. They want the shortest path to that solution. Anything that makes the path longer will result in people just giving up and not buying anything from you.

If something feels too complicated for you, someone building the product, it is definitely way too complicated for a user.

Lesson #9: Copy other apps.

There are a lot of excellent product teams out their shipping amazing products. Why not just reuse what they’ve already figured out? It’s much easier to ask designers and engineers to just copy something instead of building it from scratch.

Anytime you interact with a piece of software, be mindful of the decisions that went into it. Take screenshots and notes. Start building out a library of things you like that you can refer to later. Building delightful products requires excellent taste, and that’s developed by being observant and opinionated.

Lesson #10: The last 10% of a feature takes as much time as the first 90%.

The devil is in the details. It’s impossible to anticipate all the complexity that is going to arise during implementation. When planning, keep in mind that something that seems really easy usually won’t be.

Usually this complexity comes at the end, once the feature feels like it’s almost ready. Adjust your expectations accordingly. Don’t get mad at your engineers when it feels like they’ve been almost done for a long time.

This post was originally on our blog, Founders Confidential. We have lots of other useful content over there :)