Building an Execution Engine, Part 2: Process

This is the third in a series of four posts on building a high velocity startup.

In Startups and the Art of Asking Questions, I wrote about a basic framework within which most startups operate. Startups need to be built to ask questions of the market at high velocity, using three primary factors: people, process and tools.

I described ways to solve for the first factor, and get the best people into your startup, in Building an Execution Engine, Part 1: People.

This post will talk about the second factor: processes you can put in place to ensure that the people in your startup are highly productive.

Building an Execution Engine, Part 3: Tools talks about the tools and systems you should use in your startup to enable execution at high velocity and quality.

In the early days of a startup, things can be fairly ad hoc: features can go directly from “that’s a cool idea” into full blown implementation, code can be pushed directly to production without code reviews or tests, and everyone can know what everyone else is working on without any special effort. As the team grows and real users start using your product, you will probably want to put systems in place that allow your team to make progress efficiently and reliably while not requiring n*n communication (that is, communication between every pair of people in your startup).

The development process in a startup needs to satisfy a number of different constraints, some of which are the same as in any company, and some of which are unique to being a startup. Some of the constraints that will shape your process are discussed below.

You need to be able to ship at high velocity

Startups need to be able to make rapid changes to their product while product-market fit is still being established. This means that shipping quickly and iteratively often trumps many other considerations, including factors like whether code is properly structured, whether every class has unit tests, and whether the brand identity is being properly maintained on all screens.

Many features that are in the early versions of a startup’s product aren’t going to be around three months later because nobody used them, and the code needs to be just good enough to allow experimentation and learning from real users.

You need to avoid build-up of technical debt

The rapid pace of product development means that building up some technical debt is inevitable. I’ll re-emphasize that some technical debt is ok, if it allows you to iterate more quickly on your product, and gather data about what your users find valuable. However, you should plan to reduce technical debt as an ongoing commitment — through refactoring, rewriting code, adding missing tests, and other activities.

This work can be done either in bursts of time that are scheduled — “feature freeze” periods when the entire team works on making the code better, rather than adding more features — or interleaved into the regular product development cycle. I prefer the second approach, and believe that the team should set aside time in every sprint to work on things that are related to engineering infrastructure and code quality.

You need to have many voices at the table, but clear decision makers

Startups are inherently about making decisions with incomplete data: about features to build, markets to tackle, and the user segments to go after. Product direction can be justified using quantitative data (clickstream data, A/B tests and others), but qualitative methods such as customer discovery, comparison with comparable products, or intuition are often more useful.

Involve your engineering team in making product decisions, especially when using sources that are ambiguous or subjective. Use both ad hoc discussions and formal design review meetings to gather feedback from everyone on the team. Good engineers know what great products look like, and involving them in the product design process will result in a better product.

At the same time, it’s important to make it clear that the final decision is made by the product manager or other product leader on the team, so that you do not slow down while waiting for consensus among the team. Gather input from many team members, make a decision, and move on.

Involving other team members in the process also helps ensure team buy-in to whatever decision is eventually made; most people only want to be heard, but understand that their opinion may not be the one chosen.

You need to be able to communicate decisions across the company quickly and efficiently

When you have multiple development teams working on different areas of your product, you need a way to communicate what one team is working on to another. A common way to to do this is to have a “scrum of scrums”, a meeting where product managers from each team talk about what their team is working on. These meetings are useful, but usually involve only product managers, not engineers.

To make product decisions from each team visible to engineers and other people across the company, consider having periodic “product direction” meetings to talk about the roadmap and the decisions that have been made. It may also be useful to involve engineers from other teams in design review meetings for product features. This both broadens the range of input you get for the feature, and exposes the tradeoffs and decisions that each team is making to engineers outside the team.

What would a process that satisfies the above constraints look like? Here’s one I’ve used before, though there are many others; pick the one that fits the circumstances at your company.

1. Projects go through a series of gates where they are refined and exposed to the team. The first gate could be a kickoff meeting with important stakeholders (the founder, the head of product etc) to get buy-in for the project. A design review meeting is used to involve engineers in ballpark effort estimation, which allows for creating a rough plan for the MVP and subsequent releases. If the project is complex enough, it’s also often useful to write a formal technical design document and discuss it at a technical design review meeting. These steps ensure that there are many voices at the table when decisions are being made, and involves engineers early in the process to allow building the project without unnecessary technical debt.
2. Projects are broken up into small, decoupled units of work. Since the majority of the technical research for a project is done before the technical design review, it is clear what the dependencies between various parts of the project are before implementation starts. This allows for creating small, bite-sized tasks that have well-defined interactions with other pieces of the project. Feature toggles allow you to ship these individual pieces of work to production without having real users encounter the new functionality. The result is a high velocity of shipping useful code to production, with a final task to “switch on” the entire project to real users when the MVP implementation is complete.
3. Product managers regularly have meetings to discuss product roadmaps with the entire company. These meetings can be as often as every week, or as infrequently as once a quarter. The goal of the product roadmap meetings is to make the entire team aware of the projects each development team is working on. It’s often also useful for product managers to have regular “wishlist” meetings with user-facing departments of the company, that capture learnings about users that can be incorporated into the product.

Hiring good people is a core component of your execution engine, and a well-designed process that allows those people to work together productively helps your execution engine stay in high gear. Pay attention to the process your team uses as closely as you do to the people you hire into your company, and carefully change the process you use as the company evolves and expands.

Read the next post in this series here.