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." <text-author>- General Patton<text-author>

"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." <text-author>- Marty Cagan<text-author>

"We are stubborn on vision. We are flexible on details." <text-author>- Steve Jobs<text-author>

‍

How an idea becomes product 💡

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:

• Take in ideas from everywhere – your own ideas, the rest of the company, competitors, customers. Keeping this top of funnel for ideas wide open is important. Engineers are an especially useful source of ideas if they’re given space to understand the user.
• Work out what’s highest leverage. What will deliver the most progress towards company goals per hour spent?
• Pick the thing to work on, and create a hypothesis for it. A useful template could be:
  • Insight: We have observed or learned X about our customers…
  • Therefore: … which makes us think that if we do Y…
  • Behaviour: … users will do behaviour Z…
  • Measure: … which we’ll measure by A.
• Do customer research on it. Make sure customers have the problem that you’re trying to solve to minimise the risk of wasted time.
• Design the product/feature, then put it in front of users. See how they react to it, whether using static designs or a clickable prototype.
• Start building. Break the work down into the smallest incremental pieces that will help you to learn if your hypothesis is true.
  Once it’s ready, ask users to walk through it to see if they use it as expected, and if you need to refine at all.
• Launch!

‍

Team Ceremonies 👩🏽‍💻🧑🏻‍💻👨🏾‍💻

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.

Standups

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.

Retrospectives

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:

• What’s going well, that we should keep doing?
• What’s going badly, that we should stop doing?
• What don’t we do, that we should start doing?

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.

Planning

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:

‍

Planning and review cycles 🔮

Quarterly planning

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.

What it looks like:

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.

Team autonomy:

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.

Presentation:

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.

Metrics:

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:

• “We are going to reduce customer contacts, without harming customer satisfaction”.
• “We are going to increase conversion rates, without harming average revenue per customer”.
• “We are going to reduce server costs, without harming our uptime metrics”.

‍

💡 Author’s opinion: OKRs

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.

‍

💡 Author’s opinion: Setting targets

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.

‍

Fortnightly planning

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.

‍

🥊 Sprints vs Kanban:

This might be also controversial, but I don’t believe there is a meaningful difference between these methods at an early stage company. The main thing is that the team is aligned and shipping fast. I believe any product methodology should only be used for the benefit of the team.
You can combine, hack, or throw away as you see fit. Just worry about getting the principles right. That’s probably what’s most Agile anyway, right?
Teams should semi-regularly evaluate their software-building approach, to ensure they’re constantly evolving with what’s best for them. A growing team and organisation may be served well starting with Kanban and may need to move to Sprints, or vice-versa.

‍

Weekly reporting

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:

• shipped from last week
• focus this coming week
• highlights (what went well)
• lowlights (what can be improved)

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.

‍

💡 Important note:

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.

‍

Roadmaps and deadlines 🗺

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.

Roadmaps

• Put the focus on problems the team will solve or value it will bring, rather than exact features. For example – “this team will focus on improving conversion”, rather than “this team will ship a new signup flow”.
• Don’t put too much focus on teams producing roadmaps. Once per quarter is enough to create alignment. Teams can spend too long keeping a roadmap exactly up to date, and the more autonomy they’re given, the faster they can ship.
• Rely on hard deadlines as little as possible, for reasons outlined above. Deadlines are sometimes needed for other teams in the business, so more below…

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.

Deadlines

• If deadlines are needed in your business, set the expectations clearly for everyone. Make sure product teams know why they’re needed, and make sure the rest of the business knows that product teams are operating in uncertainty.
• Giving ranges that narrow over time is a lot more palatable than giving exact dates. It aligns with the uncertainty that product teams work with.
• Make sure product teams update on changes to deadline ranges as soon as they know them. This will keep everyone’s faith in whatever information they’re given.

‍

💡 Roadmaps and agility:

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.

‍

Bugs vs Tech Debt vs Features 🐞

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:

1. You under-prioritise bugs: if bugs are a major issue in your product but you set aside a specific amount of resource on it, you might not work on something major.
2. You over-prioritise bugs: If the bugs being worked on are low-impact, then it’s sub-optimal to fix them above other work.
   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.