Despite everyone’s best intentions, business rarely goes to plan. There is always turbulence, ups and downs, with constant surprises. The pressures change, and the need to survive or achieve targets is ever-present. Life will be dull if business plans leapt off the page into reality.
Targets really do matter
Leaders and founders are typically under revenue pressure. In funded startups, ambitious financial targets are often at risk of being missed, and the board of directors demand growth. When a company repeatedly misses commercial targets, many founders are under emotional stress. It includes the fears such as:
- Will I have to lay people off?
- Will I make payroll this month?
- How long is left on our runway?
- Will the competitor beat us?
- Will I get diluted and lose control and money?
Obsession with revenue drives short-term decisions
So hitting targets, which can sometimes feel arbitrary to teams in the business, can really matter. Given this familiar landscape, it is only human for leadership to bias decision-making towards fast revenue wins. Unfortunately, this is too often the foundation for future disasters.
An example of fast revenue decision-making would be in a SaaS business when the HiPPO (Highest Paid Persons Opinion) rules to build a feature justified by closing a single deal. I call this “Closing Code”, and it is rarely a good idea. This behaviour can accidentally become a leadership addiction, eventually crippling the company’s potential.
Writing code to close deals is a dangerous drug
Like with a drug, agreeing to prioritise the “Closing Code” gives a short-lived shot of positivity and confidence. There is an immediate feeling of relief from the pressure and stress. The reality is all sales teams are faced with objections lowering their confidence to close deals, this does not warrant custom development or the associated costs. The SaaS business model formula only creates high value if you sell a line of code to many customers. In this model, if you spend money on custom code for one customer and sell it in the SaaS model, the return is unlikely to cover the time and materials costs to build the feature. In short – it is terrible business practice.
An objection every software sales professional has heard is, “Oh, it doesn’t support this feature”. The feedback to leadership from sales evolves into “If we had this feature, I am confident we can close the deal”. If you’re a product manager reading this, you know how this too-frequent story ends, ie a c-suite decision is made to prioritise building the feature, despite your protest about the value of the feature.
When the desired feature is either so uniquely bespoke it’s never been discussed before, or it is buried in a product backlog where ideas go to decompose (probably for a good reason), we have a case of “Closing Code”. The actual cost of building the feature is typically not considered. The opportunity cost is often very high, impacting the mid to long-term revenue, but this is a problem for tomorrow, and leadership can be quick to make the mistake of pushing the issue down the road.
Writing “Closing Code” is unlikely to be profitable
Having analysed numerous instances of “Closing Code”, there is a typical pattern. “Closing Code” powers short-lived revenue spurt. After every “Closing Code” is signed off, it has to be delivered, so the impact reduces when the development queue to build the customisations becomes too long.
The problem, like many things that are not good for us in the long run, is the first time doesn’t hurt in an obvious way. A strategic product initiative gets delayed by a couple of sprints, the impact isn’t significant. So, it is soon followed by another “Closing Code” customisation and another. The accumulative effect quickly compounds. Customisations are delivered later than expected, causing expectation management challenges and frustration.
As “Closing Code” customisations queue up, the business model has accidentally changed; the company is now behaving like a software agency but with the accounting and governance of a product company. This is a disaster.
Shocking as it may sound, the “Closing Code” customisations often cost more in product development effort than the deal was worth. That is right, not only has the deal got CAC (customer acquisition costs) to payback before contributing profit, it now has additional development costs which may never payback. With no controls in place, it is common for £20k to £100k development efforts to be spent. The average product engineering team costs the business £25k to £30k per 2 week iteration or sprint. Very few teams track the actual costs of a feature.
“Closing Code” delivers a specific client need and from the perspective of a single customer. The solution created is normally so nuanced to the client that it can only be sold once.
Adding insult to injury, product analytics from tools like Pendo etc show some of these “must-have” deal-making customisations are not even being used by the customer. When this is the case, the reality is the deal woud have been closed without the feature.
Strategic product initiatives can make or break next year
As the company year approaches the end, next year’s budget raises its head. Remember those strategic initiatives which we pushed down the road, now we have to face up to what it means to have delayed these. Typically a bunch of product development was planned and modelled into multi-year business forecasts, the intention being new features will drive growth in the following year. However, little to none of that product development has been started and is a long way off from being delivered. Now the board of directors want to know why the product leader hasn’t delivered the strategic dependencies for growth. This is painful and regularly sees product leaders leave the employer.
The pain doesn’t stop there. All those customisations delivered in a hurry are now being described by engineering as tech debt. Engineers are now slower at making changes to the code base resulting in yet more delay and expense.
This is how the drug of “Closing Code” kills growth and eventually destroys the potential for a company to scale.
How to avoid “Closing Code”.
As product leaders, it is tough, but you must remind your founder and leadership teams of the impact any short-term bias will have. The best way is to:
- Focus on transparency of development costs,
- Share feature adoption,
- Reframe the question from “shall we build x”, to “shall we delay this strategic initiaitive”,
- Have roadmaps with limited spots for content, ie swapping things out on the roadmap never adding.
- Share customer evidence and soundbytes to inform decisions,
- Log key decisions in your lightweight governance process.
Product leaders must align leadership towards a clear product vision and a product strategy to achieve the vision. Demonstrating with evidence how the product strategy will create value and being able to measure progress against the strategic plan is vital. Short-term decisions can be replaced with strategic bets only by increasing the focus on what is being missed out on.
It helps if your product strategy is articulated using the Product VCP (Value Creation Plan) with user metrics focusing on valuable user behaviours you need to create or modify. A strategy that can be easily measured allows everyone to see the work done but also the work to do. It is vital that product leaders present the cost of making a decision which includes money spent and opportunity cost.
You can learn more about the Product VCP in this set of articles which introduces it and guides you step by step to building it https://www.righttoleft.io/blog/how-to-execute-your-product-strategy.
Comments 0