Stop Drowning in Feature Requests, Start Delivering Real Value
In todays digital world, individuals and businesses have more choice than ever when it comes to choosing software. The rise of SaaS has led to a decline in initial implementation costs, meaning customers are no longer bound to products and services long-term while trying to recoup their initial investment. The reduction of long-term contracts and increased choice has made the market place for software more competitive than ever, resulting in customers demanding more and more from their software providers in order to win and retain their business.
In the world of software development, customer demands tend to come in the shape of product feature requests. To stay competitive, software providers are finding themselves committing to more and more of these requests and timelines, putting additional strain on the people and processes put in place to deliver them. This over-promising often leads to huge product backlogs, unachievable timelines, unhappy customers and burnt-out employees.
So what measures can be put in place to help reduce the flow of these requests while vastly improving their quality? How can we realign our customers expectations in a way that doesn’t prompt them to go and seek services elsewhere? How can you deliver the best possible product for your customer without necessarily saying “yes” to every feature?
This article offers advice to those in this situation and is written from my own personal experience, detailing what steps my team and I took to regain control of our product and get back to delivering real measurable value to our customers.
- Define Your Product Vision
A product vision put simply is the overall goal for your product, the reason for its creation and positive change that it will bring to the lives of its users. It serves as your North Star, helping guide you and your team through each and every product decision. It helps provide clarity to your customers as to where the product is headed, instilling trust and confidence that the product is moving forward. Your product vision should be bold, inspiring and achievable, it should stick in peoples mind, it should give people absolute clarity on where your product is headed and why.
Your product vision should be bold, inspiring and achievable
If you don’t have a product vision or if you do, but it’s not visible then this should be your first change. Don’t think that it’s too late, even creating a vision after the product has launched will still add value, just make sure that you make it visible to your colleagues and customers. Once you have your vision visible, use it to qualify both incoming requests and the ones already existing within your backlog. Those items that align with your vision should be prioritised and moved toward the top, those items that don’t align should either be discarded or devalued.
When your customers are clear on your vision, they will be much more likely to align their requests with it and think twice about raising ones that don’t. This will reduce the amount of features being raised while having the added benefit of ensuring the ones that do, are more likely to deliver greater value.
Those backlog items that do not align with your vision should either be discarded or devalued
Every good product should start with a vision but it’s never too late to create one — like firing an arrow, you having to pull back before you can go forwards. Visions created after product launch will still add value, but make sure you communicate this with both your team and your customers. Know your vision and know where you are headed, then use this to help shape which features you do and which you don’t. Don’t prolong your product journey by developing features that don’t align of your vision, instead focus on high-value, vision-aligned features and watch your product grow.
2. Think Like a Detective
As Product Managers, we like to think that each one of our customers’ feature requests has been put through the same stringent criteria that we would put our own ideas through. We assume that requests have been thoroughly thought-out, have passed an internal review board, users have been interviewed and all other avenues have been discounted. Unfortunately this is rarely the case.
Remember your customers are not Product Managers.
Remember that your customers are not Product Managers. They will not think about products in the same way that you do. Customers will rarely consider the effort required to deliver the feature, whether there are any possible workarounds or whether their idea is indeed the best way to solve the problem at hand. It is your job therefore, as Product Manager, to try and ascertain this information by careful but thorough questioning.
Start by trying to answer the following questions:
- What is the business process and how will this add value?
- What is the pain point this will solve?
- How many and what user(s) will benefit?
- How important is this feature to the customer?
- What are the dependancies?
Personally, I like to ask “Why?” as many times as possible to try and strip away the request layer by layer until you get down to the real pain-point. You may find that the requirement requires a totally different approach than the one suggested by your customers. Take the following example:
C: I’d really like it if your app worked on my phone.
C: So that I can check on how my shops are performing when out and about.
C: So that I can offer them support if they are under performing.
C: Because better performing shops mean a better performing company.
Okay, so originally our customer asked for our product to be delivered via an App. However, after digging deeper, we found that our customer would just like to know how their shops are performing so that support could be offered.
PM: Okay, so how about we set up an automated report that gets delivered to your inbox showing your shops previous days performance?
C: Well, that would be great.
PM: Okay, I’ll speak to someone in the project team and get that setup for you. You should have it in your inbox by tomorrow AM.
By simply asking a few questions we have managed to establish the root-cause of the problem. Not only that, but we have managed to deliver a solution that solves the customers pain-point, requiring no additional development. The customer is happy and you just saved yourself months of development.
3) Remove Dates and Features From Your Roadmap
A mistake I see people making all the time is including too much detail on their product roadmaps. Detail such as the release date of every planned release, lists of features that are going to be delivered in those releases and detailed screenshots of how the features will work. Don’t make this mistake.
Including detail like this on your Roadmap means your product schedule will become instantly inflexible throughout the period you have included. Once your Roadmap is made public and is in the hands of your customers, it will be very difficult to backtrack on these commitments. You can forget adding caveats to the end of the presentation saying things like “a roadmap is not a promise”, the damage will have already been done.
What you have essentially done here is promise a fixed scope and a fixed time, which means that unless you can hire more developers (cost) who can be trained quick enough to make an impact, you have committed a cardinal sin as far as Product Management goes. As humans we are notoriously bad as estimation, we struggle to even estimate how much work we’ll do in a sprint, how do you expect to estimate what features you’ll be delivering in 18 months time? It only takes you landing a large new account or discover some significant technical debt that needs repaying and your entire plan has just gone out of the window. This approach ultimately just leads to missed timelines and disappointed customers.
For more information on the Iron Planning Triangle, Atlasssian have written a comprehensive article explaining the model and how it differs from Waterfall to Agile — well worth a read.
Regardless of our Product Management best practice, our customers are still going to want at least a rough idea of what features will be delivered and when. So how can you still communicate valuable information about your products trajectory, without committing yourself long-term? The answer is refreshing simple — Goal Orientated Roadmaps.
As the name suggests, this type of roadmap describes goals you will set out to achieve during a release but not full disclosure of the detail behind what this will entail. For example, the goal for the next release could be “to deliver the platform via a native app”. Not only will this goal keep your team focused on the aim of the release but it also allows a certain flexibility on the release scope. Say for example, you go on to deliver the platform via a native app, but there wasn’t enough time to include the print functionality, then you have still achieved the goal you set out to and your customers will appreciate that.
Closer to each release, you can produce a feature certainty document which gives customers a list of features you are targeting in the next release in order of priority — where the highest priority items are started first. This way customers know they can almost certainly expect features at the top of the list but not be disappointed should a feature at the bottom of the list not be delivered.
This idea links back to the Iron Triangle of Planning mentioned earlier. Goal orientated roadmaps fit in with Agile approach to this model as it allows for scope to be the flex while keeping time and cost fixed. If you do come across a situation where scope has to be fixed, then I would look to flex the date and perhaps mention a quarter for a release instead of a date or month, although try and avoid this where possible.
4. Look to Determine Real Value
As we have established, over promising can often lead to ‘feature deficit’, where more items are coming into the backlog than are coming out of it. Over time, this will lead to product backlogs so large that there will be no hope of ever delivering all of the items within a relevant timeframe.
If you find yourself in this situation then you need to start clearing some of the ‘dead-wood’ from your backlog and trying to find features that will deliver significant value. One of the ways my team and I do this is by placing each item on an effort vs. impact scale. Basically, you rate each item (roughly) on how long it will take to develop and how much business value it will add once developed. Plot a quadrant chart onto a whiteboard or screen and plot your items onto the chart. Image thanks to Game Storming.
Generally speaking, anything that scores high-effort / low-impact should be rejected immediately. Any item that falls into the low-effort / high-impact should be sent straight to the top of the backlog. The other two quadrants both fall into the ‘Maybe’ pile — consider these carefully before developing them and if you do, start in the high-effort / high-value pile.
There are many other ways to ascertain the value in your backlog. This is just a very quick way to gain clarity on which items should be developed first and which should be put into the trash. There are plenty of other great methods out there you could use, if you find this one over simplified.
5. Learn How and When to Say “No”
As Product Managers, we pride ourselves on building great relationships with our customers. They gain transparency of our roadmap, development practises and releases; sharing the highs and the lows.
The challenge of having great relationships with your customers is the perceived damage you may do by saying “No” to some of their product feature requests. It is somewhat of a paradox but the greatest customer relationships tend to be the ones where you do say “No” to from time-to-time, especially to those low-value features or those not aligned with your vision. This is because by saying no to the chaff, you are enabling yourself to deliver the most possible value for your customers which inevitably leads to product satisfaction and healthy customer relationships.
This idea can be linked to The Wolf and Sheep Model. In this model, the Wolf is arrogant and cocksure, ignoring his customers and their feedback. The Sheep on the other hand, is weak and easily-lead and therefore just agrees to everything his customers ask. In this model, both the Wolf and the Sheep are extremes of this scale, neither one resulting in happy customers or the success of your product.
The key to success therefore, is striking the right balance between driving home the product vision (Wolf) and listening to your customers feedback (Sheep), ensuring each product iteration is focused equally on both. Ensure your customers know where your product is headed and how you intend to get there but don’t leave them out in the cold. Try to select customer-requested features that do add value to your product and do align with your vision. Mastering this is how you can progress your product at breakneck speed, bringing your happy customers along with you.
Like an old friend, let your customers to ride shotgun with you on your epic product journey — while you are doing the driving, they can often give some helpful pointers as to the route you take.
Just remember to stop for pee breaks!