So you’ve decided on the general outlines of what you want to build. You have an engineering team, designers, PMs. It’s time to figure out who works on what, what order to build things in, what you are really building, and so on. It’s time to get to the nitty gritty of building a product.
What’s the best way to actually do this? There are a lot of methodologies out there – agile, scrum, kanban, waterfall, and so on. I don’t really subscribe to any of them, but instead I can tell you the general outlines of what I’ve done in the past, some principals that work, some pitfalls to look out for.
Let’s start with the question of goal setting.
A good practice that I took away from Google is starting with quarterly OKRs. OKRs stand for “objectives and key results.” You make a list of the things you want the team to get done (e.g. improve onboarding) and for each one of those things specify the metric that lets you measure it (e.g. % of users who complete onboarding goes from 60% to 80%).
These Objectives should generally be outcome driven goals (e.g. improve performance, improve conversion, improve customer satisfaction) rather than output goals (e.g. minimize JS, put button in a different spot on page; add chat widget to homepage).
The Key Results can be numeric metrics (if possible) or output oriented if it’s not yet possible to attach a reasonable number to the goal. If you are too early in your development process then the result you are shooting for might just be building and launching the thing, rather than moving a metric.
Here are some OKRs from my last company:
- Improve our ability to edit photos to match a customer’s brand
- Increase positive outcome rate to 70%
- Reduce revisions citing “Doesn’t match style” to 3%
- Improve the performance of our image specialists
- Increase positive outcome rate to 70%
- Reduce revisions citing “Looks fake” or “Didn’t follow my instructions” to 10%
- Improve the growth rate of our customers and their engagement in our app
- Increase % of members using the planner weekly to 50%
- Increase median time in app to 4:00
- Increase members’ followers by 10% MoM (median)
Notice that we were going for very specific changes in metrics. I’ll speak more to the question of whether you should be prioritizing completing features or driving customer outcomes in a bit.
You make this list at the beginning of the quarter and spend the next three months working on it and tracking your progress. You’ll want to check on how you are tracking on these goals every month at a minimum. Importantly, at the end of the quarter, before making your next list you go back and grade yourself on how you did on the last one.
The grades should be pretty high-level; I like to use a green/yellow/red framework: green = you nailed it; yellow = some progress but incomplete; red = you missed it. The grading keeps you accountable to yourself and the rest of the company.
Quarterly OKRs should not appear out of thin air as a diktat of a single product leader. Instead there should be a collaborative process for arriving at them. The exact process doesn’t matter that much, but it needs to synthesize data from a lot of different points.
Those data points ideally include input from users, engineers, PMs, designers, sales, marketing, and other stakeholders. Common ways of getting this data are surveys, retros, feedback-emails, bug reports, NPS surveys, etc.
Good ideas come from everywhere and gathering input with a wide net is a good idea. But, at the end of the day, someone needs to decide what the real priorities are and be able to justify them to the larger team.
Deciding what not to do is just as important as deciding what to do.
At a small startup the ultimate decider is the CEO or CTO. At a bigger one it might be a VP of Product or Engineering. At a place like Google it’s typically the tech lead, eng manager or PM. OKRs roll up through an organization, so there will be OKRs of increasing scope the higher up in the org you get.
The way the decider should pick what to work on is by looking at a lot of different factors and arriving at a stack rank. Then you choose as many of the items from the top of the list as you have resources to get done.
And these decisions should happen pretty quickly. If you are spending more than a week or at most two deciding on what to work on, then you are spending too long. You need to move fast.
Which brings me to the topic of prioritization…
I’ve had to prioritize a lot of projects and the only thing I’m certain of on the topic is that no matter how you prioritize someone is going to think you are doing it wrong.
To start, let’s admit that prioritization is a hard problem, and you are not going to come up with a perfect solution. You will never know if the priority order you came up with was the right one.
The best you can do is use a reasonable framework and come up with your best guess and get on with building.
That said, it’s good to start by judging candidate projects along a few big dimensions:
- Impact: how big of a deal will it be if you get the project done – how much does it help you hit the OKR?
- Effort: How much work is it? How long will it take?
- Risk: Can you actually build it? And, if you do, are you sure it will achieve the desired outcome?
- Definition: How scoped is the work? Do you actually know what you want to build?
- Resources: Do you have the right resources available to work on the project?
E.g. say you are building an asset library for a photo editing tool. You might weigh one feature that lets users find content on the web and upload it themselves against another that uses machine learning to find and identify content. The first would probably be lower risk and lower effort, but also lower impact. The second (the ML solution) could be risky, take longer and be harder to scope but might have a bigger payoff. It also might require special resources in terms of engineering talent and data.
The goal, per above, is to make sure you hit the OKRs. Typically you do this by maximizing impact and reducing effort and risk. In our hypothetical asset library example you would weigh the difference in impact, effort, etc and make a judgement call on whether the extra risk and effort was worth the payoff.
In the real world though things are rarely so simple and if you do prioritization just based on the above, you’re likely to land in a world of pain. There are other things to consider…
You need to make sure the engineers on the team are happy and working on things they find interesting. If you don’t you may have attrition. You also will have less productivity as engineers stop working as hard, start coming in late, feel demotivated and so on. You want missionaries not mercenaries on your team.
You need to make sure that engineers are on a growth path and being prepared for promotion at some point. Every engineer wants better skills, a higher salary, and more responsibility. Some projects lend themselves more to growth than others.
You don’t want anyone idling. Everyone should be engaged in productive work at all times. This can be tough to manage because the features you most want people working on might not be specced for a while. If specs aren’t ready, you can also have engineers working on the product discovery process by prototyping and feasibility testing.
You want to make sure that pressing bugs and other one-off issues are addressed. Often these will not fit neatly under one of your OKRs, but you still need to fix them.
You want to be flexible enough that if some new but important issue arises you aren’t slavishly following the OKRs. This happens all the time at startups.
You want redundancy in who knows different areas of the codebase in case an engineer decides to move on.
You have to accommodate vacation, parental leaves, sick days.
You have to recognize that engineers are not fungible. They know different parts of the stack, different technologies, different parts of the codebase, and will work on projects at different rates with different quality outputs.
You sometimes need to build things to increase company value in some strategic way that might not be directly tied to a user story (say for an investor demo).
The things you build can’t just be the product of a stack rank. They need to blend into a cohesive product.
You may want to bundle certain features for a specific launch.
And so on…
In short, figuring out who should work on what, and in what order, is a big constraint maximization problem that has no clear best answer. Putting together a simple spreadsheet that weighs the options can be helpful, and I recommend it.
At the end of the day, you want a set of goals that are high impact, cohesive, and the team can rally behind. You want something that can be packaged into a neat effort that you can attach a launch deadline to. The results should be measurable and something everyone on the team can work towards.
But ultimately it’s a judgement call to be made (and defended) by the product decider. Like I said, someone is going to be unhappy. But it’s your job to get agreement to move the project forward if not agreement on the actual priorities.
Once you have your overall priorities and roadmap set, it’s time to start working on a week by week cadence.
What has worked best for my teams in the past is dividing up tasks into weekly sprints. Two-week sprints are ok as well. Every sprint should be kicked off by a short weekly meeting where each engineer and designer publicly commits to what they are going to get done that week.
A few points here:
- The things that you want to get done that week should be visible in some public place. It could be a shared spreadsheet, a tool like Asana or Trello or Jira, or just a plain document. Don’t obsess on the format. What matters is that it’s visible to all.
- It’s important to start the week with everyone publicly saying to the whole team that they are going to get X done. For more senior engineers on the team, they should be coming up themselves with what X is. For less senior folks, the engineering manager should assign tasks and communicate them Either way it’s important that the engineers themselves commit. This creates accountability within the team.
- X should be sized appropriately for a week. This can be tricky, but check with the engineer or designer to make your best guess. I’ve tried to use point systems or other sizing methodologies, but I have never found them to work particularly well. But I’m not against them. Be pragmatic and don’t get caught up looking for the perfect process.
- X should be scoped and defined so that everyone knows what it actually is.
Here’s an example weekly task list from my last company:
As mentioned, the exact format doesn’t much matter – this one was a google doc that linked out to Asana tasks that had more granular detail on the tasks. We could have done this same type of list in a spreadsheet or in Asana itself, but we liked the simplicity and readability of the Google Doc.
After the engineers and designers have made their commitments for the week, I suggest sending them to some larger group outside of the product team. This could be a higher up manager, the sales or marketing team, the CEO, etc. Sending the weekly plan outside of the product team creates whole team accountability and gives visibility as to what is currently being worked on.
The thing you send should also highlight what you got done last week.
I recommend starting every day except the day of the product team meeting with a short team standup. I’ve seen standups work a number of ways (and not work at all).
The point of the standup is to discover issues that could prevent folks from reaching their weekly goal. It’s the main tool an engineering manager and PM has for understanding what is going on, what is blocking the team, etc.
The mechanics are simple: get every person on product team in the same room in the morning at a fixed time and have each person say:
- What they got done yesterday
- What they are going to get done today
- What they are blocked on or need help with
- And that’s it.
Each person should talk for less than 30 seconds.
Good issues to surface:
- Engineers blocked on code reviews
- Engineers blocked on design input / not sure how to build something
- Engineers stuck on difficult bugs and needing help
- Engineers being behind on tasks and needing help
- Engineers and dev/ops stuck on deployment cycles and bad merges
- Designers needing input and/or feedback
- Two people working on the same thing by accident
- Two people working in a way likely to cause a conflict
- Bad bugs that have come in during the week and how they are being fixed
Things to look out for:
- Do not get into deep technical discussions in standups. Anytime this is happening you should move the discussion to after the standup.
- Do not try to define features or debate priorities during standup. Keep things short.
The standup is the main way that engineering managers and PMs are able to see if the team is on track for the week. If not, it’s an appropriate time to adjust and rebalance tasks, unblock folks, and so on.
Standups tend to deteriorate in attendance and quality over time. I’ve seen this again and again. Engineers start coming in late, the standup gets cancelled a few days when lots of folks are out, the standup goes badly a few times, standup updates start to come in via slack rather than in person.
When this happens it is the job of the team leaders to get it back on track. The standup deteriorates because engineers would rather not do it. It requires them coming in at a fixed time, it pulls them away from their computers and forces them to talk in front of a group. But it’s important to do because without it, you, as a leader, will not know what’s going on with the team.
At my last company I literally resorted to taking attendance. Each engineer had a “standup streak:” the number of consecutive standups they had attended in a row. There were rewards for hitting certain milestones – ten straight standups got you a free coffee, and so on. It felt like elementary school, but, when we pushed it, it worked.
A few folks have asked what I have against Slack standups. I’ll probably write a section on when I think Slack is appropriate (not that often), but I definitely don’t like it for standups because:
- Slack updates aren’t interactive in the same way as in person – it’s much harder to ask questions quickly
- New slack messages push the standup updates out of the window (i find this to be a general issue with any kind of group slack)
- They tend not to all come at the same time, which causes the standup to actually take longer and cause more distraction
As an aside, I’ve come across many folks in the product world whom I consider overly-dogmatic about product process. People tend to hold something like religious beliefs on how things need to be done.
This is not me. I’ve tried a lot of different systems, tools, and so on, and what I think works best is a pragmatic approach. Do what makes the most sense in the context of your product, team, stage, company, culture and so on.
For instance, if you are a very early stage startup with no product, it doesn’t make a lot of sense to base your OKRs on moving customer metrics. You should base your OKRs on getting your MVP built as quickly as possible. The Key Results should be MVP features.
The specific product planning tools you use rarely matter in my experience. At Google, it was a set of in-house tools. Externally I have used Asana, spreadsheets, documents, github tasks. The more advanced tools have various bells and whistles, which can enable some advanced workflows.
What actually matters is commitment to a process and constant vigilance by the management. And more than that, what matters is the culture you build. If the culture favors pragmatism and a commitment to putting the user first, then you will likely be successful no matter what the particulars of the process are.