How to Build Great Tech Products

A Guide for Product Managers and Growth Leaders

product managementtech

Why this article?

Almost all resources out there contain generic advice on product management, which isn’t very useful to someone who’s actually looking to practice it. So, I decided to gather some concrete examples of how and why tech products succeed and the stories of the heroes behind those products.

This article contains actionable insights from the successes and failures of 4 product leaders, all of whom ultimately built successful products.

Jeff Lawson

CEO of Twilio.

• Lessons from Twilio’s journey: 1) Know exactly what you want to accomplish and who your customers are 2) Have conviction in your hypothesis even if (especially if) it is against conventional wisdom
• Build something that you need, or at least what you would use (or would have used) at some point in your life. Before you write a single line of code, talk to potential users to see if there’s even a real need for it (i.e., are you solving a real problem?)
• Always have the willingness to try new products, new things. You never know when your “side product” can become your main business. Follow your customers — if they ask for new features or products and you think it’s a cool idea, try it out.
• Follow your gut. It’s okay to make mistakes but it’s not okay to not try at all or do something you’re not convinced about. Sometimes getting distracted by chasing the shiny things isn’t so bad, but you need to balance exploration (try new stuff) with exploitation (investing in your core product). Manage your resources (time, money, effort) well.
• You don’t know what’s going to be the next big thing so you can’t just have 1 big bet. Don’t put all your apples in a single basket. Have multiple bets which all have the potential to be the game changer. Increasing the number of such bets you make also increases your odds of success.
• When you run experiments or build new products, don’t expect them to become giant businesses overnight. Don’t measure them in dollars but instead in how much you learnt from it.
• When you learn you’re onto something, when your customers are growing, when your product’s becoming successful, be willing to invest heavily into it. Double down in real time when you see the signs of success.
• Build strong relationships with your customers. Once you have users, try your best to retain them. If your customer is a business and is paying millions of dollars, you better have sales reps that are regularly in touch with them and keeping them happy. Customer service is essential especially when there’s no shortage of competitors in your industry. So it’s in both yours as well as the customer’s interest to know what they’re thinking so you can try and help them (and consequently retain them).
• When things go wrong, do a post-mortem to figure out the root cause. When things go right, do a post-mortem to figure out the key principles or lessons that can be generalized. In short, treat every experience, good or bad, as a case study and analyze it so it helps you in the future.
• Good decisions sometimes lead to bad outcomes. Bad decisions sometimes lead to good outcomes. There’s a lot of luck involved, but on average: make good choices, great things happen.
• If a single bug by a developer can break an entire website, don’t blame the developer (after all, humans always make mistakes). Figure out the root cause — why was there ever a system that would fail entirely because of a single mistake? Ask “Why” 5 times to figure out the root cause (in fact, someone once told me that asking “Why” 5 times is enough to make someone cry).
• “Every day, our goal is to suck a little bit less” — accept that there are some things your company is not good at but just try to improve on those things.
• Write things down. PowerPoint cannot be used as a decision making tool — don’t mix emotions with decisions that need to be analyzed rationally. Use the written word to argue the case and make decisions based on detailed analysis, not flimsy PowerPoint slides. Bullet points destroy information — and the devil lies in the details. When you abstract away the details too much, ideas get lost — you lose touch with reality.
• In fact, the act of writing a narrative essay explaining an idea without having intellectual clarity yourself is really hard, so it forces you to know what you’re talking about. In contrast, in PowerPoint you can just shove in the keywords, some good charts, and bullshit your way through the talk. Whenever you want clarity of thought, try it write it down.
• Ruthlessly prioritize. If the executive team never argues, it’s a problem. It’s a sign that everyone’s getting their way, which means that there’s too much on the “goals list”. But if you restrict the number of goals to 3, people would start arguing about which goals are more important than others. So, prioritizing lead to (necessary) arguments and disagreements that help to clarify the vision of the company.
• Your budget is your priorities. First decide what you want to get done — debate this rigorously. When you’re allocating budget, allocate based on the priorities.
• Goals should be prioritized (numbered in order of importance) and their metrics (to determine whether a goal has been met or not) must be clearly written down too. In fact, if you have multiple metrics, you should list them in order of importance. This is better than OKRs because objectives aren’t ordered, and people tend to focus too much on the measures. The benefit of priorities is that they communicate the commander’s intent — what exactly are we trying to achieve?
• Don’t be obsessed with measures. Measures just tell you whether you’re on the right path. Charting the right path is the real hard part.
• If you’re not in close proximity to the customers, you can’t feel the impact of the product you’re developing and that sucks the passion out of it (and it feels like clerical work). If you’re just building something based on the specs of a PM (who heard stuff from the sales team), everyone feels disconnected from the real customer and you feel as if it’s all hearsay. Instead companies should ensure all employees can see the big picture and the part they play in it so that they feel inspired by it and can execute it to perfection. (This is how startups work because you basically have to do everything and the complexity is small enough to keep in your head).
• For every team, define the customer, a mission, and the metrics to evaluate progress. Keep teams small enough to function as a startup. Scale erects walls — people start working dispassionately in silos and don’t care about the big picture, and you should try hard to avoid this.

David Lieb

Senior Director of Google Photos.

• Don’t take no for an answer. Sometimes it’s okay to be stubborn and stick to your guns.
• Show, not tell. It’s easier for people to understand what you’re saying when you show them (using a demo). Give a transformational presentation that inspires people. Go above and beyond.
• Have the confidence that the problem you’re solving is real and when you build the product, users will come. But your confidence needs to be based on at least some evidence. It’s better to have a small group of people love your product than lots of people just like your product. This small group of people will rally for you, give you feedback, and be your cheerleaders.
• To get others to help you, you need to help others too.
• Acquisitions are a great way to get smart people who have diverse perspectives to join your company.
• How to hire the right people? 1) They need to have the same values — this is non-negotiable 2) They need to be aligned with the company’s mission. 3) They need to be confident, independent thinkers who will bring a different perspective and disagree with you. Their confidence needs to be credible — do they have any previous experience or learning? Do they know what they’re talking about or are they just confidently rambling nonsense? (So you need high level alignment but you also want disagreements in which paths to take to reach the final goal)
• Best questions to ask: “If you were the owner of product X, what would you do? What would you change? How would you implement that? Why are you so confident about that?” Poke people deeper and deeper to separate the bullshitters from the real learners.
• The most dangerous kind of person to hire is someone who’s confident but can’t articulate why he’s confident in his opinion. It just means the confidence is unfounded and likely unrealistic. It’s just so tiring to interact with such kind of people who always think they’re right but can’t even explain why.
• User retention is sometimes harder than user acquisition. Figure out both.
• What do you do when you don’t know what to do (for consumer products)? Go talk to users. Ask them which features they like, don’t like, how frequently they use it, etc. Don’t ask them super vague/general questions (e.g. what are some pain points in your life) because they rarely ever elicit valuable insights. Ask specific questions about the product (e.g. why do you use our product?) or a feature or anything that you can work on. Sometimes users are using your product for a completely different use-case than you intended. Understand the motivations of users — ask WHY.
• How to find real problems? Ask yourself: what are some minor inconveniences or annoyances you face in your day? Dig into those because they may be symptoms of a deeper, much bigger problem. Then ask others (your friends, family) whether they face similar problems too.
• If you think you should fire somebody, you should fire them.
• Don’t discount ideas you think might not be appealing to a lot of people. Have a portfolio of product bets, each with a different level of conviction. If a feature is not very hard to build but has the potential to give great returns, just do it (even if the probability of success is low).
• Attention to detail + going deep into the problem is the key to being a successful product managers. The higher your seniority, the more you lose touch with the actual product (yet the more decision-making you do, which makes it dangerous). You also need to convince people to disagree with you, by inspiring them. The best product managers understand the capabilities of their tech and design team and they plan accordingly.
• Ask yourself how excited you feel about building this product? If you’re not excited about it, how are you going to get users excited about it? Be honest to yourself while doing this little thought exercise. Change the narrative to inspire yourself or change what you’re building.

Nate Stewart

Chief Product Officer at Cockroach Labs.

• Have a clear roadmap for what the company is about, and say NO to customers whose use-case doesn’t align with your product. They may go to your competitors and that might be demoralizing but have the conviction that your strategy will eventually lead to success.
• Dogfooding is super important — if you’re an engineer, use what you build so you know its advantages, disadvantages, use-cases, etc. better than anyone else. It’ll also show you ways to improve the product, and how actual users would be interacting with the product (so you have a better sense of what you’re building).
• A company’s strategy should match it’s capabilities and skill sets. If you don’t have security experts, how do you plan on keeping data secure, and customers to trust you with sensitive data? This is often why strategies that may sound good in theory often fail in the real world — it’s a skill issue.
• A lot of companies these days believe in “don’t focus on your competitors focus on your product and your customers” and that’s bad advice. You’re not the only company in the industry — and you need to know what others are doing so you know where to position yourself vis-a-vis others (e.g. during sales pitches, you need to be able to differentiate yourself from competitors).
• Measure how much real users are using the different services and features so you know what to focus on improving.
• Consider holding “product council meetings” — every month, get the product manager to write down a long narrative on how things are going, where things are headed, and get the heads of all departments (sales/marketing/engineers) to silently read the document during the meeting and leave comments. The PM can collate the questions and in the next half of the meeting, they can have a conversation around these questions. For such meetings, try to only include people who are relevant (7–10 pax).
• PMs need to define problems very specifically (set the acceptance criteria but not how to reach them) — don’t lead the engineers to solutions. Let the engineers come up with innovative solution.
• Don’t commit to a customer without knowing how much time and effort you would need to spend on the solution (from a technical point of view as well). Only commit stuff you think would accelerate your roadmap, not distract you from it, or solutions that solve a bigger problem than you were originally intending to solve.
• Manage your ego. Your strategy can be wrong and it’s okay — don’t try to fight it when you’re wrong. Accept it and make the change necessary.
• Actively seek feedback and reflect on it. Try to get high quality actionable feedback from people. Ask them for specific things you can improve on.
• If you act like a defensive jerk when someone gives you real honest feedback, it’s unlikely that they’ll ever give you such feedback again and that’s your loss.

Melissa Tan

Head of Growth at DropBox and Webflow.

• Do specific user research — get detailed pain points of the user, especially if the product is complicated to use. Take big swings — do unconventional things to solve those pain points. Get them to talk out loud as they use the product, not rely on their memory of the experience but the experience itself. It’s more real and hits different compared to reading a synthesis of their experience.
• Building a great product is not sufficient if it’s too complex to use — you need to teach users how to use the product. (Also do user research on how users prefer to learn — videos, blogs, live sessions, etc — and use the right mode of teaching)
• Identify the “points of influence” — points during the user journey where users make key decisions — and try to focus on making sure those go as smoothly as possible.
• Get users invested in the product early on (e.g. in Webflow, they found that users are more likely to finish setting up their website if they already bought a domain) to reduce drop-off rates. Psychologically, this makes perfect sense — it’s a classic example of sunk cost where you’ve already spent some time and effort (and maybe even money) on something and so you’re less likely to drop out of the journey.
• Develop user empathy — encourage them to continue and offer help at every step. Make sure they feel like you’re with them every step of the way. Get users to feel a sense of urgency to start using the product. Show them what they stand to lose if they delay using the product.
• Invest in layout. Poor UI/UX is one of the main reasons people don’t like using products — they just don’t feel good about it. If your UI/UX is bad you need to provide a LOT of value to be able to compensate for the terrible experience. On the other hand, if your UI/UX is good, users will be more tolerant of some minor bugs.
• Make sure your success metrics are easily and accurately measurable (e.g. time spent by users per day, daily active users, etc.). Also, they should be such that they can be measured quickly so you can see the change in metrics to assess your progress. Close the feedback loop using these metrics and improve using what insights you gain by analysing these metrics.
• Make sure the metrics make sense and everyone’s on the same page about them. Once you’re confident that the metrics can accurately measure the success of the product, be extremely results oriented. You can’t (and shouldn’t) hide from the data.
• Not all trends to be explainable so don’t try to find explanations for everything. Some trends may be purely random or seasonal.
• Knowledge sharing between teams is super important — get teams to fill in reports asynchronously and share them with everyone (so those interested can learn from it).
• As usual, have long term goals as well as short term targets (that are derived from the bigger goals) aimed at achieving those goals (translate goals into actionable steps)
• It’s okay to be measuring tons of metrics but you can’t be optimizing all of them. At most you can optimize a couple of metrics, without it being counterproductive to the other ones.
• How to improve user retention? Use an annual subscription model, offer discounts.
• When to get a “growth person”? Either when founders have no more bandwidth to work on growth or when you’ve hit a ceiling and you need a growth expert to drastically expand the startup.
• What background do growth experts need to have? Attributes are more important than experience — needs to be analytical, user-centric, data-centric, thinking from first-principles, flexible, learner’s mindset
• Pricing and packaging? You never know what’s going to be your core go-to market strategy is going to be but it’s got to be scalable. But you need to think about it early on — who are you building the product for and how much are they willing to pay for it? Also, you should include PMs in the conversation to decide the price for features because they are close to the features and how much value it adds to the users.
• Think long term when it comes to product roadmaps. Don’t monetize X if you can monetize Y (which would give more revenue) and offer X for free if it can drive the sales of Y up. That is, don’t think of each pricing decision as being individual and isolated — they must all fit into the bigger picture.
• Price changes are difficult and need to be executed/launched properly, especially if you already have a large user base. Brace yourself that if you increase prices, you might lose some customers (and that’s not necessarily bad) — you can’t have your cake and eat it too. Of course, any price increase should be matched with value increase (feature addition, etc). You should know how much increase in price each user segment is going to face and run the numbers ahead of time. Lastly, your messaging (how you communicate the price change) needs to be clear, effective and empathetic. Test it on some people in your community to see the reactions it engenders before rolling it out to everyone.

That’s all! 😅

Btw, if you haven’t read Ben Horowitz’s “Good Product Manager/Bad Product Manager”, it’s a must-read for anyone interested in learning how to build great products.

References

Podcasts by In-Depth on Spotify:

1. “Building a Highly Technical Enterprise Product” — Nate Stewart
2. “How to Design A High Impact Growth Org for a PLG Startup” — Melissa Tan
3. “CEO of Twilio Jeff Lawson Reflects on the Peaks and Valleys”
4. “Growing a Consumer Product from Scratch to 1 Billion Users” — David Lieb