Software planning for the startup CTO
At the beginning of a venture, everyone wears a lot of hats. On the sales side, the CEO may be cold calling every day, while the CTO may be writing code for every feature. That quickly becomes a poor use of time for those key players, but it is a long time before you’re able to fully entrust those responsibilities to other employees, but, you have to scale. For CTOs, one main area is usually writing code. A lot of times the CTO is the technical expert on the new algorithm or novel product you’re creating. It can be one of the hardest things for a CTO to let go as you scale.
Early on, there are a ton of decisions that need to be made about the technology, and that responsibility is critical to the viability of the company and often a bad idea to give up if the CTO is also the technical leader. However, as a startup grows from 2 to 10, then from 10 to 20, then from 20 to 50, the technology and the team stratifies. If the CTO is still in the weeds making the day-to-day technical decisions, a huge portion of the business critical decisions are simply left unmade.
While there are a veritable ton of growing pains and problems, I’m going to focus on this stratification and how it impacts the product planning cycle. As I’ve interacted with a number of managers at companies of all sizes, and all levels of seniority, a common theme is properly understanding the altitude at which different individuals need to think. If you’re in a 200 person team, and the CTO feels the need to touch every ticket, not only are they going to quickly feel overwhelmed, but they’re going to be ineffective. Conversely, if you’re on a 5 person team trying out a bunch of iterations to get product market fit, spending half of your time on strategic planning may not be the best use of time. Each of these different levels of planning are needed, but in the right measure and at the right times.
When you’re the CTO, you quickly change altitudes and bounce between those many times per day. In the morning you’re in standup talking about why ticket 122 is blocked in code review, and how to unblock it. In the afternoon, you’re in an investor meeting talking about how your product will be a category creator, and how your platform play is the real billion dollar product. In the evening, you’re back to making suggestions in code review. And, finally, before bed, you’re rewriting a key algorithm to be 10x faster. It’s a lot.
It is likely that you’re making great decisions about where to spend technical time, and doing great work with your 15 hour days, but it doesn’t scale. When you double in size, your hours in the day don’t double as well. You will have to focus your time, and start firing yourself from jobs.
One of the jobs that is both critical to a companies success, and is very time consuming is product planning. When you have 5 developers writing code, it becomes a nearly full time job simply making sure requirements for every feature and ticket are correct, and well-defined enough to write code for.
One framework I use to help define this process is below. This focuses on planning — that mysterious intersection between engineering and product. As CTO, you spend a lot of time in this process, and are in a constant race to stay ahead of your developers and dev teams. This framework helps break down the different altitudes at which you and your team should be thinking about planning.
Let’s break this down a bit. There are 4 levels here:
1) Cards (& Code)
2) Epics
3) Features
4) Initiatives
Let’s define what each means.
Cards & Code
This is where teams break apart epics into discrete units of work. Generally this is the first (and most granular) thing you start tracking in a project management tool. In general, this is mostly handled by your scrum teams, your developers, your architects, your product owners, and your QA team. This level of definition is the bridge between the product side of the house and the technical teams. Once efforts are defined at this level, you can generate a good idea of when things will be completed, as everyone has had a voice in the process.
Epics
This focuses on larger deliverables in your codebase. Where a card may be “Add time card CRUD API”, the epic may be adding the time tracking widget to the individual dashboard. These generally track whole, complete units of value to customers. This manifests as a collection of stories that give us a new unit of value to customers. Epics usually come with requirements docs, and UI designs, and when ready, get broken out into stories and assigned to developers/sprints by the team. You should have a strong grasp on the requirements of the currently “In Progress” Epics.
Features
These are large themes in your planning process. Generally this takes the form of multiple epics that provide a customer experience. While adding the time tracking widget to the individual dashboard may be a complete element of the application, it’s not really completed until we have added the time tracking report, integrated it into the payroll system, and created the hours logging databases. In general, these are the things you sell to customers: “Oh, you’re looking for a software that ALSO does time tracking, we will have the released in the next version!” At this level, things are a bit amorphous, being defined by customer pains and feedback only. This would be the level of planning you talk about when roadmapping. It’s all about taking a swath of customer pain, grouping it, and defining the product solution.
Initiatives
These are the squishy, larger goals in the idea stage. Sitting somewhere between a broad problem statement and a known problem, this generally represents a “known unknown” from a product standpoint. The market may be telling you people are unhappy with their time tracking systems, and you are trying to give them a better product experience. For a lot of 0–1 companies, you may only have one initiative for the first few years. This is less of a CTO question, and more of an existential question for the entire founding team. Plans here forecast how you fully capture that huge TAM from your pitch deck. While you may only have one or two, having this aspirational roadmap helps keep the company aligned around a vision and a goal.
Applying this at different stages of growth
As CTO, you’re always planning for the next iteration of the product. Using this framework at various stages of company growth can help you frame and make a number of critical decisions around planning, hiring, and process. I’ll go through a few examples of how this can help at various stages:
2–5 people
You’ve just started, and you may not have fully left your day jobs yet. A lot of the decision making is a community effort with all of the founders. Your entire goal is around proving the MVP, and getting potential customers to imagine how a fully formed product will change their lives.
As you transition from founder-coded product, to hiring your first one or two engineers, you will need to start planning and coordinating efforts. You may start bringing in your first tracking system for cards and bugs. You’ll start building a backlog of items [and a lot of bugs].
This is the time to start collecting the backlog of cards into epics. You’re learning faster than you can build [by a lot], and will need to start aggressively prioritizing chunks of work to show customers what your product is capable of.
Cards: You’re planned out 1–2 sprints
Epics: You have a ton in theory, but they’re generally scoped right before they start work.
Features: There’s one. The whole team is up at night hoping it comes out.
Initiatives: Your whole product is a single goal at this stage, and most likely still being formed as you spend time with potential customers.
5–10 people
You’ve started to grow, and as a CTO, you’re starting to let go of some of the coding. You’re more focused on scoping out what each feature needs to look like, and what elements will go into the product.
You’re starting to build a backlog of well-formed product ideas in the shape of epics, and you’re spending a lot of time getting wireframes and requirements created, while also playing chief architect. You should start to pull in your first product hire, or a product focused senior engineer to help with the planning process.
Potential places to start to share the planning responsibility are: hiring your first product manager to help plan epics and features, getting a senior engineer to help build the technical requirements for epics, or formalizing the team’s planning sessions to break epics into cards.
Cards: You should have a good grasp on the next 1–2 months of cards, your team should be providing estimates, and you should start to gain confidence around your team’s cadence and estimates.
Epics: You should have 1–2 months of Epics well-scoped and ready for development. You should have a further 2–3 months of epics being defined and planned.
Features: You should have 2 or 3 well-defined features that the team is making progress on. These will generally be targeted to solving customer objections your sales team is running into.
Initiatives: You still have the one goal, but it’s starting to be more well defined. You’re getting a grasp of what your future will look like, and from that, a lot of internal product ideas from the team.
10–20 people
You have at least one well-oiled team in place. Between design, product, architecture, and the rest of the team, you have a solid process for defining epics and features, and you’re getting confident that the requirements your team is creating are high quality.
You’ve also started to work on multiple features at once. As CTO, you are spending more time running the product process and are writing almost no code. You will be starting to manage the team that is responsible for a lot of the day-to-day planning work. You’re also no longer in every product or customer problem conversation, and most likely have a key product person.
You’re focused more on strategic direction, and starting to think about your features as pieces of larger product offerings, and will be starting to develop longer term roadmaps, as well as additional product offerings.
Cards: You still have about 2–3 months worth of cards planned, but have a formal process for defining these as new epics and features are defined.
Epics: You have 2–3 months worth of epics well planned, and have cards created, but an additional 2–3 months of epics defined as part of your features.
Features: You have a strong sense of what your next 6 -12 months will look like. This is important, as you will start to burndown against these quickly as you scale in the next iteration. Building a product process to support this should be a key goal.
Initiatives: You have one well defined product, and set of customer needs to drive you through the next year or two. You should also be thinking of additional product lines and avenues that your product can grow into. While this is still a team decision, everyone has strong confidence that the initial product line is developing nicely.
… and Beyond
As you continue to grow, you still have to plan development effort, but this will start to become a product unit exercise. As CTO, once you have a well defined planning process, you can replicate it across multiple teams and product lines or offerings.
With that growth, you’ll also find that you’re not the only one making these decisions and the people you bring onto the team will help further define this process. The product experts and team leads will both help you build great process, and will ultimately run it as you continue to scale. This framework gives you another tool in your tool belt as you work with the team to identify and solve problems. Having a framework to understand at which altitude the current problem is, and how different roles should be operating, can help you zero in on communication, scope, and planning process issues.