5 THINGS PRODUCT MANAGERS NEED TO KNOW to DRIVE ROI – Part 2, COST
In my first article, I addressed important drivers of the revenue portion of product ROI, but knowing how to affect cost is at least as important, if not more, because all costs savings drop right to the bottom of your P&L. For example, if you’re running a $30 million business with a COGS of 20%, Operating Expense of 40%, and a valuation multiple of 10:1, your company’s valuation would be approximately $120 million. If you reduce your expenses by 10% ($3 Million), then your company valuation would be roughly $150 million – an increase of $30 million!
Suffice it to say, product managers should be aware of what they need to know to manage costs and increase their product ROI.
KEY COST DRIVERS
#1: Risky product development prioritization process I’m continually surprised by executives who are resistant to using a product development prioritization process that requires key stakeholders to provide a numeric rating system tied to the things considered most important to drive product ROI. The resistance I’ve seen does not typically come from product managers, however, it’s usually from executives who don’t believe in ‘all that stifling corporate process’, because they just ‘know’ what the market needs. I’ll never forget one such senior executive I worked with who said, “We’re not interested in all that b.s., we move quickly around here and have a good feel for the market, and no ranking process is going to replace our gut instincts.” The problem with this approach, aside from causing product managers to shake their heads in disbelief, is that humans are notoriously bad at being objective, and at ‘knowing what they don’t know’. By using a structured approach to decision making, based on data, combined with subjective expertise based on experience, your likelihood of spending development dollars and things that you can actually monetize is much, much higher than if you rely on the ‘gut feel’ opinions of a few well intentioned stakeholders.
(As a side note, the executive I referred to happened to be CEO, and later went on to use his ‘gut feel’ to push a very expensive new product development effort that not only failed to solve any big problems that the market actually wanted to pay for (except for the one big customer who asked for it), it was also outside of the company’s core competency. As no surprise to the product management team, it was fraught with quality problems from the beginning because the company didn’t have the skills to implement and support it, and beyond that one big customer, almost nobody else wanted it. After burning nearly 9 months of valuable development time and money, and incurring a large ‘opportunity cost’ of foregoing other development projects that would be valued by a majority of their customers, he was fired by the board members who were not terribly impressed with his ‘bravado’.)
#2: Quality: Product Maintenance / Bug Fixes When companies decide to short change the investment needed for thorough quality testing before going to market with products, as the old saying goes, they are being ‘penny-wise and pound foolish’. The cost of serious product defects after they are in-market is exponentially higher, in both real dollars and opportunity cost, than if proper quality assurance was done before releasing them. In the software business, for example, not only does it take more time for development to address these bugs after the fact, each unhappy customer consumes support time, impacts satisfaction ratings, harms referrals for sales, reduces development time available for new product development and innovation, and the list goes on.
(It’s worth noting that I sometimes encounter product and development folks who are resistant to spending too much time on QA because in their opinion, it would slow down their Agile and Lean processes and reduce their iteration time for innovation. I’ve reminded them that though it’s true that some bugs are worth fixing and others aren’t, a ‘minimum viable product’ in LEAN methodology means creating minimum functionality to start with, then iterating your way to success based on market needs; however, it also means that the functionality that you do provide should work as intended!)
#3: Technical Debt Like QA, under-investing in your product platform falls into the same ‘penny-wise and pound foolish’ category as above. I’ve often seen companies who are under such pressure for performance by their investors or shareholders that they continuously defer necessary investment in their infrastructure to support products. Although it’s true that your market is not likely to pay you more for upgrading your product technology platform, you still need to consider every investment from a market-perspective. To some, this is counter-intuitive – if the market won’t pay for it why should we do it?
First, consider that the definition of ‘paying’ means not only getting more revenue for what you provide, but also retaining revenue that you already have. If a platform upgrade is required to keep your customers happy, it’s justified.
Second, your ability to increase or sustain your pricing levels is contingent on providing customer experiences that meet or exceed customer expectations, and keeping your platform up to date may be an important part of that experience. To use the analogy, consider the value of your own home. When it comes time to sell it, motivate buyers will generally pay more things such as a remodeled room, new garage, or beautiful aesthetics. They usually won’t give you more just because you fixed the plumbing or replaced the windows; however, if you don’t have the infrastructure up to date, they will certainly pay you less!
Third, you need to look at ROI with a long-term perspective. When building a business case for platform investment, I typically use at least three and preferably a five-year horizon when calculating ROI and NPV for technology investments. To assess strategic impact of an investment, I’d consider an even longer time horizon.
Finally, although customers may not often say it out loud, they expect that you are looking ahead into the future to make sure that the product they purchase today is still viable for years down the road. New customers will expect that when the time comes for them to purchase your product, it is up-to-date and competitive with other alternatives, which means product management needs to be looking ahead to what those needs will be. Existing customers will also expect that you are anticipating the need for technology upgrades even if they don’t ask for them, and if you don’t, they’ll start shopping around when your product seems antiquated.
#4: Customer Support Especially for complex and expensive products, such as B2B software, customers expect to receive sufficient support’ however, costs to provide it can quickly erode your margins, especially as you introduce more products and complexity. To control these costs, here are a few helpful hints.
First, don’t assume that your support should be a ‘one size fits all’ approach. Depending on the price customers are paying, you may need to charge extra for certain kinds of support that go beyond a reasonable baseline expectation. You also may need to consider what support levels are included or excluded from your product/service packages, and segment according the market needs and willingness to pay.
Second, especially in the software business, the more different versions of the same product that are being supported, the higher your support cost. This is because each version may require slightly different knowledge & tools to provide support. As time progresses, it’s important to manage a careful balance of ‘carrots and sticks’ to both pull and push your customers onto a smaller number of versions that you can more easily support. In the end, your costs will be lower and customers will be happier, but you need to skillfully manage the transition.
Third, when designing your products, make sure you keep the entire customer experience in mind, starting with their journey even before they buy your product. In simple terms, make sure you’ve planned for how make your product ‘Easy to Learn about, Purchase, Set-up, Use and Support.’ You’ll drive more revenue and reduce your costs to support the products, and significantly boost your product ROI.
#5: Development Productivity This sounds so obvious, you might wonder why I’d even include it in this list. While it’s true that your Product Development Managers should make sure their teams have the skills, tools and motivation to be productive, there are things that Product Managers can do that have a huge impact on development productivity as well.
First, when you are creating your strategic product roadmap, be sure to include research to validate whether the new product concepts that you think are needed by the market (based on your market research to determine problems to solve), are in fact what a majority of your customers value the most. To get this information, it does not necessarily mean you need to first build product diagrams, prototypes or wireframes to show them. It just means that you need objective information about problems to be solved via some combination of surveys, interviews or other research. By doing so, you can determine whether you’re prioritizing the right ones, and that customers will value them enough to be monetizable (or that they must be done for them to keep paying you.) An extra few weeks and some minimal investment in research time at this phase will dramatically increase your chances of success, and as importantly, you guessed it – reduce wasted product development hours.
Second, make sure your product managers are equipped with a process and template for creating product requirements that is replicable, easy to understand, specific, and documented so that your development team can more easily interpret them, and avoid wasted development hours due to miscommunication. Even with an Agile process, it’s important to have a thorough Marketing Requirements Document to provide the right foundation and guidance for agile iterations. It’s also important to have a consistent template into which to define these requirements so that you don’t forget to cover important topics, but also so that your product development team can more quickly understand the information, and develop their own processes, aligned with your template, to transform your high-level requirements into more detailed ‘technical product requirements’ and/or ‘product specifications.’ I am NOT advocating a waterfall approach, but even in an Agile methodology, certain documentation is essential. (If you’d like to see the ‘Detailed Marketing Requirements’ template I’ve created for this purpose, please contact me at jhanson@marketviewconsulting.com).
Third, before defining the product concepts and creating marketing requirements, product managers should have already defined the target market, target segments within that market(s), target customer personas for relevant buyer types, and a succinct definition of what problems the product will solve that these target segments will pay for, and that are needed by a majority of customers in those targets.
Fourth, in addition to defining requirements, they should spend some time defining examples of markets and segments that are NOT targeted, and customer problems that the product is NOT intended to solve. It’s just as important for key stakeholders to review and approve these as it is for the requirements. This provides further clarity about the intended focus for product development and also helps product managers control scope creep down the road, when the inevitable request comes from sales, customers, other stakeholders or developers who have a cool idea that they feel like working on! The bottom line is that development is difficult, expensive and fraught with risk, so the more focused you are on things the market truly needs, and not distracted by other ‘shiny objects’, the more successful you’ll be.
In summary, these are just a few of many cost drivers that your product managers should be aware of. If you know of others, please share them with a ‘reply’ to this post, or e-mail me at jhanson@marketviewconsulting.com.
John Hanson is President of MarketView Consulting, LLC, which helps companies monetize more value with a repeatable product management process for discovering & delivering what the market wants and will pay for. For more information, please contact John via e-mail (jhanson@marketviewconsulting.com), or by calling 651-261-0344.
