Building a product is a simple exercise. Find a problem and build a solution to solve the problem. Think of being in the wilderness: you need shelter, so you build a lean-to; you need a place to rest, so you build a raised bed of logs; you need heat, so you build a fire pit. To build these products, you probably do some planning: how big a shelter, how wide a bed, how deep a fire pit. Then you build. And then you assess whether your product works or needs fixes: am I dry, can I sleep, am I warm.

Below is a simple, repeatable process for building products that scales from one user to millions of users. It's a process we use at Albert, the banking app I founded in 2016. Over seven years, with fewer than 30 engineers today and no product managers, we've built a checking account, savings account, investing account, fee-free overdrafts, credit score and report monitoring, identity protection, financial advice, and budgeting tools, and we serve millions of customers.

A new process

Building a product has three phases: plan, build, and measure. Everything else is a distraction.

Tech companies build products. This is their primary reason for existence. Over time, products stagnate, so companies must figure out how to keep improving. But as they grow, most tech companies struggle to ship high quality product quickly.

Tech companies have created many processes, roles and frameworks for building product: product managers, group product managers, scrum, agile, user stories, bug tracking software, and much more. These are mostly distractions. They nurture bloated teams that move slowly, operate by consensus, and favor incremental improvements over leaps.

Imagine you're back in the wilderness. What happens when building inspectors, specialized contractors and interior designers arrive to work on your lean-to? They'll sit in meetings while you're freezing in the cold.

Of course, we need contractors and inspectors and designers. "If you want to go fast, go alone; if you want to go far, go together," the saying goes. But the way we work with others when building a product matters a lot. The wrong—perhaps status quo—approach leads to stagnation; the right approach drives speed and quality and can be built with a lean, efficient team.

Three phases

There are 3 phases to building product using this approach:

1. Plan. Prioritize which problems your team is going to solve.
2. Build. Design a solution and build it.
3. Measure. Determine what worked and what needs fixing. Repeat until things work.

Small teams that follow this simple framework can build almost anything. Below are templates and instructions for each phase.

Plan

To get started, you must decide which of your ideas to build. There are many ways to come up with ideas, a topic intentionally skipped in this post. Once you have ideas, you must prioritize them.

Planning is prioritizing. That is, your company likely has many ideas for features, improvements, and bug fixes. Bad prioritization leads to work on things with marginal impact, which leads to stagnation.

There are two important planning principles:

• Hell yeah, or no. Every feature or improvement requires conviction. If you're not sure, shelve it. This is critical to building things that matter.
• No backlogs. A backlog is an attic for ideas. If a team is not excited or ready to build something now (in the next few weeks), come back to it later. Individual team leaders can keep their own scrapbook of ideas to reintroduce for prioritization later. Often when you leave an idea alone, you realize that it was never worth building in the first place.

Build roadmap template

At Albert, we call our template for prioritization the Build Roadmap, or BR for short. Here's the planning process:

1. Suggest. Throughout the week, leaders add things to the BR with the status discuss. These range from large features to operational improvements.
2. Discuss. Every Monday morning the leadership team (CEO, heads of engineering, product, legal, compliance, operations) meets for 2 hours to review the ideas. Ideas are filtered with the criteria above: hell yeah, or no. Ideas that won't be built are removed.
3. Assign. For each project, agree on the next step and assign someone responsible. For example, if the next step is interface design, assign a lead designer; if the next step is building, assign an engineer. Most ideas are assigned to be worked on during the coming week, but sometimes resources are light so ideas are left in discuss for next week. Don't let projects fester unbuilt for too long—that's a backlog.

After the BR meeting, the heads of engineering and product meet with their respective teams to discuss objectives and goals and assign the work. 

Build

At Albert, we do not have product managers. We have 30 engineers, 3 product designers, and a head of product. This team has built a product with significant breadth and scale.

Investors ask us how we build so much with so few people. The answer is in this framework. We keep things simple, and we empower engineers—the builders—to act as leaders and product managers: they design the architecture and they build. You must hire talented, ambitious builders for this to work.

PRD template

Engineers write a Product Requirement Document (PRD) to outline their work. There are many PRD templates on the internet, but most are too complex. Create a very simple PRD using the template below, which focuses on substance over format.

Here's how the PRD process works, in a few steps:

1. Discuss. An accountable engineer was assigned a project in the BR planning meeting. The product designers share UI and UX designs with the accountable engineer. The engineer meets with the head of product to review the feature.
2. Design. The engineer writes a PRD. They plan the backend and frontend architecture, anticipate edge cases, provide feedback to product designers to make design adjustments, create a plan to measure the success of the product, and marshal additional resources (e.g. a backend specialist may need an iOS engineer to build the frontend). See the template below for all of the components.
3. Build. Write code. Test the code with automated tests. QA the feature on a representative sample of users.

Importantly, the same person who designs the implementation details builds. This reproduces the magic of an early startup, where things move fast because builders are free from constraints of bureaucracy.

An important finding: a QA (quality assurance) team is a crutch. Engineers design and build, so they are responsible for testing. And they are responsible for building automated tests as well. For large, important features, many people on the team test as well. It's common for the head of product and engineering to do QA. It's also common for the CEO to do QA. If leadership is not intimate with the product, what message does that send to customers?

Measure

Once you build something, measure that it works.

A product is a long string of experiments. Each feature, improvement and fix is an experiment. Experiments require measurement.

The person who designs a product's implementation understands what the product is supposed to do. This makes them suited for the final, crucial phase: measuring whether the product works. 

Suppose you release a feature that sends a welcome email to users who just joined your app. The project is only complete once you've measured that the email was sent to expected users. To measure this, you'll create a table that shows the number of users who joined every day, the number of emails sent by day, the average time from user joining to receiving the email, and the percent of emails delivered, opened, and clicked. Every feature or fix, no matter the size, requires this type of detailed measurement.

The Experiments Tracker

The experiments tracker is a table we use at Albert to track all of our running and completed experiments. It's open to the entire company. Here's the process:

1. Every time a new feature is deployed, add it to the table.
2. For weeks after release, engineers monitor their experiments. Heads of engineering and product and the CEO actively monitor all experiments as well.
3. Experiments are categorized as success or failure based on metrics. Failure is common (and important), and it only means that it's time to iterate. Most experiments require iteration.

The experiments tracker does a lot of important things: it catches bugs in real time, gives everyone at the company transparency into what's being built, provides a standardized way to gradually roll out experiments, builds a culture of iteration, and it empowers builders to be autonomous.

Putting it all together