A key role of product management (PM), whether as the product-focused founder (CEO, CTO) or the PM leader, is making sure product development efforts are focused. But what does it mean to be focused? This isn’t always as clear as it could be for a team. While everyone loves focus, there’s an equal love for agility, action, and moving “forward”. Keeping the trains running is incredibly important, but just as important and often overlooked is making sure the destination is clear.
It might sound crazy, but it is much easier than one might think for teams to move fast, get stuff done, and break things that might not be helping the overall efforts. In fact, in my experience, this challenge has become even greater in recent years with the availability of data and telemetry. With such, it becomes very easy to find work that needs to be done to improve the app or service — the data is telling you right then and there that something is tripping up customers, performing poorly, or going unused. Taking action makes it easy to feel like the right thing is happening. It feels like moving forward. Everyone loves to get stuff done. Everyone feels focused.
But is the team focused on the right work to achieve the right results?
Just a little process
Two important realities represent a constant balancing act when leading a product. As a PM you are applying finite resources to market needs in the march towards product-market fit or are working furiously to maintain a competitive lead. In addition to the new features there is the work that sales or customer success needs and together those greatly exceed what can be delivered by engineering.
This problem doesn’t ever go away and is at the core of the role of product leadership — getting the right stuff done with the right priority.
In every well-run company there is a strong tendency towards action and a strong dislike (tending to revulsion) of process. In practice, the absence of a process is just as much of a process, just one without clear lines between action and result. A little bit of process (aka product management) can go a long way to having real focus and getting the right things done.
With a little bit of process, everyone on the team can have:
- Shared views on what success looks like
- Clear understanding of success measures and metrics
- Easy mechanism to decide what should be cut or pushed out when things aren’t going as planned
- Visible alignment between what work will impact what elements of success and which measures
- Honest accounting of resources going into what big picture initiatives
- Ample opportunity to participate in deciding what gets done and when
It is very easy to overdo process and go from a helpful tool to a burden people run away from. A personal goal has always been to be as lightweight as possible and to have a way of thinking about these needs that scale from projects that last weeks, months, or even longer.
My guiding principle or golden rule of process is to never ask for something from someone that does not directly help them to get their own work done. Process is not about reports or “management”, but about making sure the work each person does is the most important work to do and the time.
Just a little framework
When most people think of coming up with a product roadmap or plan, they think of ends of a spectrum. At one end there’s commonly the one slide version labeled with months or years and a couple of bullet points at varying levels of granularity and decreasing accuracy as time goes on. There’s also the detailed and long-term strategic plan that most people can’t read through that is often the work of consultants or staff at big companies.
There’s something in between that I’ve found very helpful in terms of framing the product roadmap.
The roadmap can be represented as a hierarchy of increasing detail. It starts with a mission covering years of aspirations for the whole company. From the mission follow the goals representing the 12 months of work supported by specific metrics or measures and the various roles or disciplines in the company. Teams then come together to work on projects (or milestones in a longer term project) that take weeks and are delineated by releasing product or programs to the market. Supporting the creating of projects are the day to day tasks at the feature level representing the work of individuals.
Throughout this whole system there is ongoing telemetry that is called upon to support the company with reliable data upon which to make decisions.
Mission
Whole books have been written about mission statements or the process of developing a mission statement. Nothing makes me groan more than the idea of having a meeting to craft out a mission statement. We’ve all seen the results of these efforts that are an awkward combination of passive voice, comma splices, and breathless language. Companies exist for a reason and that’s the mission.
Missions are aspirational and guide you for years and represent the reason for being. Everything you do should aim towards your mission, and how you do that is the work of the rest of the framework. Missions boldly stating that the goal is to “disrupt” tend to be a bit backward looking or focus on the mechanism versus the outcome. Rather a mission that defines a future state of being or a new world view are often the most enduring and more positive. The most important thing about a mission is that there is just one and it endures. Mission statements are best able to be expressed on t-shirts, or something close.
Goals
Most everyone thinks they already have goals. Too often though goals are expressed as metrics or scorecards, like be the most downloaded app or number, daily users, or bookings. These are easy to express and are the lifeblood of a startup. The challenge is they change frequently. Like any good code when faced with something that changes frequently, the best bet is to add a level of indirection. A goal is the abstract view of metrics or measures.
Goals are strategic concepts such as retention, ease of use, acquisition, manageability, scale, success, and more. Through evolving telemetry you develop metrics to support the goals.
By using these abstractions you might come realize you have more goals than engineers (or marketers, success partners, etc.) or that you end up with every person working on too many goals. This is part of the process of being focused about goals. For any one product there can only be 3–5 goals and those fit on one “slide”, which includes the full spectrum of engineering, sales, and customer outcomes. This is a deliberate attempt to put in place some constraints up front.
Goals are then measured in specific ways over time. Metrics are then the lifeblood of goals. Your goal might be acquisition, but the metric might be a specific mechanism of retention for a period of time; or your goal might be to improve scalability of the service but the measure might be compute usage for some time and then storage usage for another.
When thinking about goals, they almost always fall to a specific function (or role) on the team such as marketing, sales, or engineering. Having a full accounting of the goals and the associated metrics allows you to understand what will change as the team’s work progresses — what is measured will be what changes.
Projects
Projects are easy to understand — they are the releases or programs customers and the marketplace use and hear about. A project might be, for example, a full update to the service, the app, a new entry to the market, a launch, a campaign, or a major infrastructure change. Early on it is trivial to name the projects for a company. Very quickly, however, the number of projects can balloon and become increasingly difficult to track (and potentially to justify). There are SDKs, enterprise tools, segment campaigns, apps for different platforms or support for different browsers, and more.
The key reason to maintain a clear list of active projects is because momentum in continuing some project, failing to re-allocate resources, can often be the biggest constraint in getting the important work done. It common to find yourself in the situation of maintaining a project that no longer fits with the immediate needs but there’s inertia that makes it hard to change. The most important task for product management is to make sure everyone is aware of the projects being undertaken. The more the company scales the more critical it is to know what projects are active and what commitments the team is making to those. Even in the biggest companies, there are just dozens of meaningful projects.
A project has an ending date or deadline date — not a month or a quarter (those are 30 or 90 dates) but a single date — and everyone knows when the project releases or is complete.
Tasks
When you work from mission to goals to projects, the most concrete expression of work on the team is the task. A task is the actual code to be deployed, whitepaper to be written, SEO tools that will be employed, launch event to hold, features that will be designed, and so on. While a few people might care deeply or contribute to the mission, and executives generally focus on goals, and managers live whole projects, everyone is invested in tasks.
Tasks are defined by those that will do the work and those same people (or person) will decide how long it takes. Every person contributing to a project might have dozens of tasks. Tasks should be from 1/2 to 2 days — less and the accounting is too painful and more and it is likely the work is not understood enough to reliably schedule.
There are two main benefits from spending the time to create a list of work items. First, the project overall becomes increasingly predictable which is important because of dependencies (such as front end and back end, or marketing activities). Second, when things aren’t going as well as planned there is a clear view of just how far off things are along with a pre-computed list of potential savings to be had by cutting different tasks. Whether it is Asana, Trello, Sheets, Jira or more the key is just having a system that goes beyond post-its around a monitor.
What is often overlooked is how much more effective everyone is when they know the why behind the what. Everyone will do better work if the worklist flows from specific projects which have goals that are measured in a particular way. Much of the work of this framework will prove to be making the connection from task all the way to mission.
Telemetry
One additional element that permeates all of your efforts is telemetry.
The most successful organizations are also fully instrumented organizations. Everything about code, customers, and overall engagement has telemetry.
Keeping an open mind and open eye to a whole variety of measures is super important. Just that as a matter of scale and operation, you cannot hold everyone accountable or change what is being done in response to every measure. If you’re learning something that concerns you then dig in. Maybe you’ll change your plans. But when you do need to change your plans you can do so in the context of an overall framework, not just single data points.
The combination of a framework and telemetry makes it possible to more globally maximize your return on investment. Telemetry alone risks a more local optimization. A framework by itself is just guessing.
Learning by Shipping 