To celebrate 50k subscribers to Product for Engineers, here are the 50 most important lessons we’ve learned about building successful products:
Small teams (6 people or fewer) can build great products, but they need to be given autonomy to set their own goals, prioritize their roadmap, pick metrics, talk to users, and ship code fast.
The success of a product is a result of the people who work on it. Having a high bar for hiring is critical because talent compounds. Nothing slows you down more than a bad hire who isn’t working out.
Building a great product requires trust. A lack of trust is often one of the biggest bottlenecks a team has. This is likely a result of hiring someone who isn’t a high enough level, or failing to give feedback to that person to help them improve.
Trust is also built with transparency. Work in public, have discussions in the open, and document what you’re working on. This gives everyone the context they need, and eliminates the political squabbles that plague many companies.
Rely on trust and feedback, not process. This is one of our core values. Building and scaling something people want is a nuanced problem, so we let people use their judgement. When they get it wrong, we are direct and give feedback.
Execs should share company goals; product teams (engineers) should figure out what to build to achieve them and set their own goals. Both should review that what they’re building is having an actual impact using metrics and user feedback.
Your product is downstream from your ideal customer profile (ICP). They are who you are building for and are the most important factor for helping you decide what to build. An accurate ICP will define not just which customers you target, but every aspect of your product and go-to-market strategy.
To find your ICP, take a guess and then test it. Ask questions on signup, compare retention, identify your power users, run NPS surveys. As you gain more intel (and confidence), add detail to it.
Create product principles. Ours are “provide every tool needed for evaluating success, get in first, and be the source of truth for customer and product data.” These give you a common language for discussing ideas and making decisions.
Map everything your users could want, because you’ll need it to prioritize your roadmap. This ensures you aren’t missing out on great ideas beyond the horizon.
Your product is more than just its functionality. It’s your brand and how your product is experienced by others. How much you invest in each function, the people you hire, what you decide to build, what function leads your company, your customer communication, and your pricing all matter in making you unique.
Your website is the first impression your product is making. A boring, templated one signals the product and team behind the website isn’t very strong. Creating a website unique to you and built for your ideal customer profile is a way to prevent this, and encourage users into your product.
Sometimes it’s the market’s problem, not your product. For example, when Monzo founder and YC partner Tom Blomfield was building a bill-splitting service for college friends, he got the advice to stop building and start trying to acquire new users. When he got one new user after four weeks of cold calling, he knew it was time to pivot.
If you’re going to pivot, make it big. Stewart Butterfield pivoted two video game companies into Flickr and Slack. LinkedIn co-founder Reid Hoffman says startup founders can pivot from failure to success, but only if they “slash and burn” the rest of their business. If it looks similar, go further.
As 37Signal’s Jason Fried says “You cannot validate an idea. It doesn’t exist, you have to build the thing. The market will validate it.”
Plans are useful, but sticking rigidly to them is not. Good execution should not mean executing a specific plan, but repeatedly doing the most important things. Judge people on what they ship, how often they ship, and the impact of their work, not on whether they “stuck to the plan.”
Waiting “one more week” to ship something is nearly always a bad idea. This attitude extrapolated out over months = way less momentum. The sooner you get something into the hands of users, the sooner you’ll learn if it’s something they’ll value, and how to make it better.
Reduce your work in progress. PRs should be doable in a day, start your day by responding to others’ review requests, merge whenever, ship behind a feature flag, and test in production. Each of these reduces the amount of context needed to get work done.
Shipping fast is a core part of our product development philosophy, but we realize this has trade offs. Technology procurement, planning meetings, agile rituals, metrics reviews take a back seat. Being async gives us more ability to do this.
Adopting new technologies into your product should only be done for hair-on-fire problems like excessive costs, scaling challenges, or customer needs. Potential solution technologies can be found by asking what ways your team or other teams have solved that solution themselves.
Artificial deadlines will not make your team faster. They often result in a doom loop that leads to mountains of tech debt and burn out. Instead, clear the processes that slow teams down, and give small teams the autonomy to ship fast.
Another way to ship faster is to have no design by default. Get a design system running and then leave engineers to build. When needed, have a design review and polish what’s already been shipped.
Feature flags enable product engineers to ship changes quickly, test in production, and get feedback from real users. They also mitigate risk by acting as kill switches for rollouts not working as expected.
The best type of communication at PostHog is a pull request. Compared to messages or issues, they turn feedback into impact immediately. This aligns with our bias for action and helps us create tighter feedback loops.
Make ownership clear. This makes deciding what to build much clearer and faster. Ownership-avoidant teams spend too much time planning, brainstorming, meeting, and project managing when they could just be shipping.
Engineers are capable of deciding what to build. They understand the technical constraints, see patterns across features, and can figure out how to solve a problem. They just might have an information bottleneck when it comes to what users want.
Instead of controlling the engineers, product managers should create context for product teams by analyzing product analytics, conducting user research, doing competitor research, and more.
Most people aren't Steve Jobs. They don't just "know" what to build from the start or have a grand vision. Instead, they ship things, get them into the hands of users, iterate on feedback, and repeat. The faster you do this, the better your product will be.
Hire and rely on product engineers. They have full-stack technical skills needed to build a product along with customer obsession. Yes, this means they need to talk to users, do user interviews, recruit tests for new features, collect feedback, do support, and respond to incidents.
Read The Mom Test. It will teach you how to talk to potential users about their problems. A key lesson is the two types of user interviews: problem exploration and solution validation. The first guides future product decisions. The second helps improve what you’re working on right now.
To get the most out of a user interview, know who your users are (ICP), how they’re using your product, and what you want to build next. Doing this will ensure that the interview clarifies your focus in next steps, rather than distracting and confusing you.
Out of all the things you could potentially build, support requests are one of the most “real.” A specific user has a specific problem. When you solve it, you just improved your product, other changes can’t say the same.
Doing support as an engineer encourages ownership of the full lifecycle of a product from ideation to implementation to ongoing maintenance. Each of these builds on each other by building the context on real customer pain points and the code behind the issues.
Engineers doing support shortens the loop between a problem for users and a fix being shipped. No support people, product managers, and planning processes need to get in the way. As a bonus, users love this.
Using your own product AKA dogfooding helps you ship faster, intercept problems before they reach users, deeply understand your product, and develop empathy for your users. It does not replace talking to users, getting real world feedback, and tracking real usage metrics, though.
Scratching your own itch, like our product team did with interview popups, can help validate use cases. If you’re not using your own product, but should be, it’s a sign something is wrong (and you should do something to change it).
Great product builders are always prototyping and experimenting. This means they need to be comfortable building MVPs and proofs of concept, shipping unpolished work, getting feedback, and pivoting when things aren’t working. It also means having all the skills to go from zero to built, everything from infrastructure to design.
Running a successful A/B test requires a good hypothesis explaining what you’re testing and why you’re testing it. Include the context of the test, the change, the metric, and the expected results.
When running product experiments, know that they might fail and get removed. This means you should set it up to be removed (with a feature flag) and ship the “good enough” version over the perfectly maintainable and scalable one. You can improve it later, once it succeeds.
Product experiments can be a lot “dumber” than you realize. For example, instead of building out a full feature, try a fake door test. This is where you add options or buttons with nothing behind them to check that people will click on them.
Failure is not the end of the world for product experiments. At Google, 80-90% of experiments "fail." You might think of this as a waste of time, but, at scale, 10% of successes can more than pay for all the failures. For example, an A/B test of how Bing displayed headlines boosted revenue by 12% (more than $100M at the time).
When focusing on growth, think (and prioritize) like a growth engineer. Identify a target area, figure out a metric representing that area, create a hypothesis on how to improve it, and implement as small an experiment as possible to test it.
It’s just about never too early for analytics. This makes sense for pre-launch products, but launching without analytics because “it’s too early” is a false economy. Once you launch, priorities shift from shipping as fast as possible to shipping the right thing as fast as possible.
When starting with analytics, start small. Choose a specific product or feature, track its usage with autocapture, visualize this data with trends and retention graphs, and try to ship features that improve those. The “modern data stack industrial complex” makes this seem a lot more complicated than it actual is.
Don’t know which metric to start with? We recommend activation as its upstream of other metrics, one that engineers can directly influence, and useful across the organization.
Beyond activation, retention is another critical metric for understanding the impact of what you are building. Tracking how this changes week by week can start to give you an idea of if your changes are getting users to stick around.
To measure product-market fit, check if user engagement is growing exponentially compared to user growth and that retention flattens (above 0%). After that, check that ICP users retain better than non-ICP ones and that your paying customers are part of that ICP.
Growth reviews ensure that what teams are building is having an impact on the metrics that matter, like revenue, product analytics, and user feedback. These are a main responsibility of product managers at PostHog.
If your company builds multiple products, treat each of them like a mini-startup. This means their own product decisions, pricing, revenue, costs, and coordination with customer-facing teams.
Work on a product you’re excited about. As James, PostHog co-founder, wrote in his guide to finding product-market fit:
