Imagine you have a well-established working relationship with a client, and they ask you to work on an important new project. This project is their main profit machine for next year and is going to increase their revenue by 10% while increasing the profitability of the company overall.
You need to put together a plan for the next two quarters and you realize that this client never really measures the value of the work you’ve done in the past.
Thankfully, you’ve seen this a thousand times over, and you’ve learned that measuring the work you’ve done is an integral part of roadmapping, because sometimes 5 small/easy to create features will outweigh the largest one. You also know that through your years of experience, the client won’t have to wait until the project is completed to start seeing benefits.
As you work on new projects with your clients, think about how to associate value to at minimum each milestone, and then assign a value to each feature of that milestone as you progress. This is one area that we see companies working backward in that they assume the value that it will bring rather than taking a measured approach.
For example, say you’re tasked with rebuilding a small SaaS product into a newer, long-term version. Its current iteration is a monolithic billing app that uses server-side rendering, was written in an outdated and inefficient framework, and has high dedicated server costs. The client has three goals that they want to achieve in the next six months:
- Lower the cost of running the app
- Making the app easier to maintain
- Increasing the performance of the app
Your job is broken out into a few pieces:
- Introducing an event sourcing architecture
- Separating the backend into focused microservices
This is the time where you should stop and associate overall value — which shouldn’t be terribly difficult in this case. You initially identify three types of value.
The simplest value to quantify here is cost. After analyzing the current application, you find that your client will save almost $500k in its first active year. If they are focused on growth then that could be higher, but let’s be conservative.
To put a number on this, your cycle time, throughput, and other metrics should be measured. You check your metrics, and estimate that the new app will let the team output 25% more features in the same amount of time. By reducing dependencies, your and their development teams will be more focused on building than dependency solving through meetings.
The frontend page load times, based on your tests, will average 50% faster. Your analysis showed that 85% of support tickets were due to a sluggish user experience and frustration for the end-users. This will lead to fewer support tickets, less context switching, and better customer retention — all of which are measurable.
Now you’re ready to plan your roadmap. Your goal here is to transition the old application into the new model over time – not all at once. This is the point where you want to think about the value each milestone will bring to the project.
While thinking through this, ask yourself the following questions:
- Are there any high-impact milestones that can be completed with little effort?
- Conversely, are there any low-impact milestones that will take a long time?
- For milestones with blocking work, what can we do to allow parallel development, such as API mocks or simulators?
- Which parts of the new system can be rolled out in today’s landscape, being integrated into the existing application?
Using this thought process, your roadmap will show savings over time rather than launching a new system at the end. Each milestone that’s completed will progress toward satisfying each of the goals, and you’ll be able to apply these same methods on future projects.
Assigning value to your work allows for better prioritization and gradual savings. This is something that will help you be a successful product manager or engineering lead as an external contractor or as an internal employee. While it sounds simple, almost every company we’ve come across does little in the way of measuring their output at the milestone or feature level and make decisions based on vendor sales pitches with little to no empirical evidence to support it.