Building product at a startup can feel like walking a tightrope – you want enough process to help you ship fast, but not so much to get in the way.
At Connect, we believe that creating great quality product is part science, part magic. Here we’ll cover a few processes to help early teams decide what to work on, how an idea becomes product, and how to report on progress.
Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.
General Patton
The little secret in product is that engineers are typically the best single source of innovation; yet they are not (often) even invited to the party.
Marty Cagan
We are stubborn on vision. We are flexible on details.
Steve Jobs
To start with, let’s walk through the process of turning ideas into something that your users can play with and get value from.
This varies greatly, but there are commonalities that apply across most companies. Whatever your particular process, it’s worth being deliberate and consistent about it.
The exact steps you follow will likely change based on the levels of risk and uncertainty. The more risk and uncertainty, the more you may want to validate before building.
Here’s a generic process as a starting point:
Every team is different, so we don’t like being too prescriptive about how they should work. However, there are some common ceremonies that are generally useful for every team.
Once per day, the product team gets together to update on progress. This can be either asynch or in real-time, as long as they do update each other.
It’s highly beneficial to find out what is blocking your team and get it out in the open. It’s also useful to see what people are focussing on repeatedly i.e. whether a piece of work is stuck for a while.
One of the most common challenges with standups is keeping them short. I recommend being brutal on timings if this is the case – literally have a timer and keep it to 120 seconds per person. They can always go in-depth after the standup.
Standups are also a good way to check in with team issues. For example, if someone proposes the team change it’s pull request process, daily standups are a good time to check in on how that’s progressing.
Product teams should be self-improving. They should identify how they can have more impact and take steps to get there. This makes them require less external management (where too much management can be a bottleneck in a fast moving company).
A retro is a blame-free time for a team to talk through how they can improve. They are both phenomenally useful and under-utilised.
If you haven’t done regular retros before, we suggest sending a form out beforehand for the team to fill in covering something like:
The team can then review in person together and draw out themes. What comes up from multiple team members, or frequently over time? You create actions for how to address these.
Make sure to assign actions to a person along with a date they will be completed by. These sort of tasks are far too easy to let slip. Although this work isn’t directly adding value to users, it multiplies the value the team can create.
Nazlı Ceren Binyıldırım gives her top tip for retros:
“Before collecting what’s going well and what can be improved, you can do an anonymous pulse check to see if people feel comfortable and safe to openly provide feedback on the aspects that aren’t going well. Especially junior team members might not feel comfortable with openly stating what is problematic when their boss is in the room. If you see that there is a safety and trust issue you should fix that first so that you can enable honest discussions.”
Aaron Dey echos this – he says that in addition to the conversation and documented actions from a retro, a simple sprint rating/vote taken at the start of each retro can give a voice to individual team members’ experiences.
Each team member gets one vote and the rating scale can be based on adjectives (e.g. Bad – Awesome) or numbers (e.g. 1-5) – but needs to be simple and understood.
The ratings gives a transparent view on the team’s health/happiness including how issues and improvements affect outputs and outcomes. Over time, it can help visualise patterns, provide perspective and enable conversations within a team, several teams or the whole organisation.
Tom White adds that it’s useful to set the tone at the beginning of retros, as you’re inviting feedback which can be emotive. Set the expectation that feedback is useful and not personal.
Team planning can take whatever form suits the team best. Whatever that method, it’s very useful to get together and align on priorities. This can just be for example product, design and a nominated tech lead, although it’s more useful to have everyone involved.
We’ll go into much more detail about this below:
For teams that are operating in high uncertainty (i.e. most startups), quarterly planning is a very important check-in. Three months is long enough for a team to substantially ship code and see if those bets are having the intended impact.
Each product team should come up with a plan for what they want to achieve in the next three months. This should be a list of problems to solve, ideas for how they might solve them, and metrics that will inform the team when they’ve been solved (or not).
Generally speaking, the fewer challenges a team takes on the more comprehensively they can solve those problems. At the earliest stages when there is just one team, focus will always be a bit spread out. As the org grows and splits into multiple teams, they can focus on fewer problems per team.
The problems to solve and metrics shouldn’t change in the quarter. The ideas for how to solve them can and should change, as the team should be agile and adapt as it learns.
It’s useful to put targets on the quarter, if you can set the context appropriately. Targets can motivate the whole team, help them think big, and align expectations around the company. But it’s important to note, when operating in uncertainty, sometimes you’ll miss targets. With product teams, working harder doesn’t always directly improve results.
Asking a team to set their own targets can be a useful way to find the a good middle ground.
The question of autonomy is important to consider with quarterly planning. Leadership can set missions, goals and problems for teams, but shouldn’t dictate how to solve those problems – if you want to have autonomous teams. That’s for the team to decide.
When making a plan, it’s important for the whole team to buy in. If it’s just the PM presenting a plan that the engineers and designer don’t believe in, it’s not a proper team plan.
Talking stakeholders through the plan is an important part of getting alignment and buy-in for the rest of the quarter. That meeting should feature key stakeholders that work directly with the team; company leadership; fellow product / tech leadership; and the whole team itself.
This can seem like a lot of people, but aligning on what a whole team does for three months is a high leverage use of time.
To get the most from the meeting, it’s useful to share the presentation in advance. I encourage PMs to walk key stakeholders through a few days before to get feedback, then share the deck / writeup with attendees 48hrs before.
When deciding on a metric, it’s useful to find one that a team can isolate their own impact on. If the metric is too broad (e.g. customer count) then it can be hard to understand what the team actually did.
It’s also useful to offer an anchor metric alongside the team’s metric(s). This is to keep them (metaphorically) honest, and make sure they don’t harm another important metric in the process. To walk through some examples:
I suspect this is controversial, but I don’t believe most teams really benefit from OKRs. I love the concept of having objectives, and a way to measure progress towards them. But I’ve seen teams get so wrapped up in the dogma of OKRs that they lose sight of what’s important: solving customer problems.
I prefer framing this as 1/ the team’s mission and 2/ the team’s metrics to measure progress on that mission.
Same outcome, but it gets around arguments about what is a good vs bad OKR.
Setting targets can be a double-edged sword.
The benefits are motivating a team, and educating the wider business on what the team expects the impact of their work to be. This is fine for BAU work where the scope is broadly known.
The downside is that missing targets can demotivate a team, and make them lose standing within the business. Product teams are often dealing with high uncertainty, so a team’s ability to hit targets might be inconsistent.
An alternative framing to setting targets is asking: “how might we meaningfully reduce churn?”. This sets expectations for what the team is doing, but it doesn’t attach a number for others to benchmark.
Whether you use Scrum, Kanban, or some other method, it’s important for a team to take stock of what work they’ve got coming up.
This makes sure that the team has well-scoped out pieces of work to progress with, and the PM is making priorities clear. The value is often less about the exact plan coming out of the meeting, and more about talking through priorities and running through the process together.
Product teams are in high-leverage positions. They can provide an enormous amount of value which means it’s important that the wider company knows what they’re doing.
I like to ask teams to report weekly on what they’ve done in the last week, and what they’re focussing on in the next week. This keeps everyone up to speed, and sets the expectation that teams should ship fast.
An example structure might be:
The last points are important. It’s hard for non-tech teams to understand how product teams work. By them being transparent about wins and open about where to improve, they can keep people on side.
The timings of everything mentioned here are variable. If the team needs faster feedback loops, then quarterly planning might become monthly. If they’re more confident in what they’re doing or need longer to see the impact of projects, then 6 monthly might make more sense.
These are two of the most common artefacts of product processes. I personally believe the importance of both is overemphasised, although they do have their place.
Roadmaps are particularly controversial in the product world. Product teams often operate in uncertainty, so they’re not sure what they’ll be building or how long it will take. As a result, they often don’t like roadmaps, even though roadmaps provide value to the rest of the business.
Deadlines are controversial for similar reasons. By definition, most product teams are innovating, which means they’re building things they haven’t built before. Between discovery (understanding users) and delivery (building the thing) there is so much room for change that deadlines are generally frowned upon.
That said – they also have very obvious (and needed) value to the broader business. Here’s how you can get the best of both worlds.
Markus Miller wrote a great blog post about roadmapping, which includes the following:
Everyone wants predictability: executives, investors, marketing teams, your squad. This is why you see so many huge Gantt charts full of features. They create a promise of predictability. However, you cannot expect predictability in an environment with high uncertainty and continuous, fast change. What is true today, might be outdated tomorrow. This leads to a lot of frustration, loss of trust and the perception of bad product management. The need for predictability comes from times when large and successful companies didn’t depend on creative output (such as factories). For companies with predominantly creative output, adaptability is more important than predictability, though. It is essential to understand the constant tension between the two needs, so you can actively manage expectations. The most essential change to manage this tension is to make your objectives outcome focused instead of output focused.
Generally speaking, operating in uncertainty means less value from a roadmap. I find that on a company level there is value in planning the outline of a roadmap for the next 12 months. But on a team level, quarter-to-quarter is a much better cadence.
One very common question from founders is “how should we handle bugs?”.
A common (but flawed) approach is to set resource aside to fix bugs. This sometimes is a specific engineer, sometimes it’s the whole team for a week.
You run two risks with this approach:
Either way – treating bugs differently because they’re bugs is inefficient.
Instead prioritise bugs the same way you do other work: by the value they bring when fixed, for the time required. An error in your critical flow will add a lot of value when fixed. A typo in an FAQ no one reads will add little value.
The same is true with tech debt. Rather than setting aside a specific amount of time / resource for it, instead look at what value it can bring to the business.
What is the benefit to users, or your company itself, by fixing this tech debt? If it lets you build other features faster, what will the benefit of those features be? There’s a balance to be struck.