Whether you are building your own products as a company, or build them for your clients as an agency, inevitably there are parts of the software that are considered to be ‘just necessary’ and another part that brings value to the end-users. In this piece, I’d like to talk about the differences between the two and look at some real-world examples where we can concentrate on doing what’s valuable versus what’s considered necessary.
First, why do I care? As a product manager, I want to make sure my products are as profitable as possible. In order to achieve that, I need to be able to project and control both the cost of change and the value that change brings to the end-user.
Having spent the last decade in this role, I have seen many instances where the change would only result in additional costs, but not in the value created for the end-user. Now, it’s one thing to pursue a product hypothesis, invest in a feature that has a negative ROI after implementation.
This is perfectly normal behaviour for a company that constantly tries to innovate, run ahead of the market and competition. Experiments are necessary and through those experiments, we will find very successful changes to our products at a cost of launching a few that are less successful and learn from our mistakes. However, often companies spend effort on changes that have no direct influence on the value for the end-users at all.
Your product, for example, may have a complex multi-layered architecture that has a high maintenance cost and a high cost of change. Every new feature you want to launch requires several kinds of engineers to be involved, each responsible for their own domain or an implementation layer. Every time you change something you pay this complexity tax.
But let me tell you something
Your users don’t care how many databases, caching layers you have, and whether your API responds within 15ms or 155ms. What your users do care about is how much value they receive from using your product, how great their user journey and overall experience is. Therefore, as a business, you need to focus all your efforts on what makes a difference for your customers, the end-users of your product. In most cases, the improvements affecting the UI and UX would have much better ROI.
Think about it
With a good UX improvement, you can influence the conversion rate, or expand your offering that affects the average order value or simply make the user journey so great that they never leave you reducing the churn rate, all of these are the multipliers in the LTV (user’s lifetime value).
You should find a way to invest as much as possible in the areas that increase the LTV and as little as possible in the rest and significantly reduce the cost of change.
Quite often it will mean radically changing the way you build products internally, covering all aspects from technologies you use to the business mindset and the kind of talent you retain in your teams. I’m not going to lie to you: the transformation is not going to be easy, but I promise it will bring great ROI and allow you to rise above the competition. As the first step on this path, you should check whether you are currently investing in things your users don’t care about, here are few examples to get you started:
Complex, over-generic architecture
Your users don’t care if you could survive the next 3 decades without changing the underlying architecture of your product, they do care about their monthly fee, which includes the complexity tax they don’t want to pay.
Solution: reduce the complexity by eliminating as many layers you have to work on as possible, ideally leaving on the frontend which is what your customers use every day.
Unit tests and integration tests
The users couldn’t care less if the building blocks are working in isolation or how well each of them plays with 3rd party service. Instead, they will leave you the moment they meet an obstacle in their journey in your product.
Solution: spend the testing budget on automated e2e tests which mimic your users’ journey as close as possible. Read more about testing what matters.
Time and the number of engineers it takes to implement a feature
Your users won’t pay you more for a change in the product because it’s more expensive for you to deliver it. They will pay you exactly what it’s worth for them and not a penny more.
Solution: move to a full-stack engineering approach where every engineer in your team can deliver any feature by herself independently. Read more about what talent you should invest in.
Expensive infrastructure
I don’t care how many different servers you run across the globe, I care about my data and your service being available to me when I need it.
Solution: move your infrastructure cost curve to closely match your usage curve with pay as you go models that serverless infrastructure offers. Avoid paying for server hours as much as possible.
Fancy development practices
Your users don’t care how agile, ISOXXX or CMMI- compliant you are, and what ceremonies you follow, but they will always abandon you for a competitor who delivers a better value faster.
Solution: focus on compressing the calendar time to deliver a feature and build your development process around it.
Here to help
Whether you are starting a new technology business, or struggle to grow an existing one, I’m always happy to chat.
Top comments (0)