post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Customer

How behavioral economics can improve product strategy

Product Roadmap

Why most product roadmaps fail: Phil Hornby (Product Leadership Coach) – ProductTank Porto

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Join us at #mtpcon London in 2025 – mark your calendars

Connecting fans to creators at Spotify (Dariusz Dziuk, Product Lead, Spotify)

Why teams often struggle with OKRs: A conversation with Jeff Gothelf

Deep dive: Crafting your product vision and mission

5 ways to invent and simplify as an AI/ML product manager

Dave is the founder of RightToLeft and the creator of the Product VCP. He is on a mission to help people become outcome leaders and support them to lead world-class product management teams. He is trusted by leaders from scale-ups and large companies such as Adobe, GitLab, Synk, Evotix, MentionMe, Contentful, BT, Rotageek and many more. In CPO roles he has supported multiple successful company exits, working with VC-backed and PE-backed companies.

Coach & Fractional CPO

Dave Martin

<p>Despite everyone&#8217;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.</p>
<h2>Targets really do matter</h2>
<p>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:</p>
<ul>
<li>Will I have to lay people off?</li>
<li>Will I make payroll this month?</li>
<li>How long is left on our runway?</li>
<li>Will the competitor beat us?</li>
<li>Will I get diluted and lose control and money?</li>
</ul>
<h2>Obsession with revenue drives short-term decisions</h2>
<p>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.</p>
<p>An example of fast revenue decision-making would be in a SaaS business when the <a href="https://www.mindtheproduct.com/dealing-with-hippos-and-big-dogs-in-product/" target="_blank" rel="noopener">HiPPO (Highest Paid Persons Opinion)</a> 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.</p>
<h2>Writing code to close deals is a dangerous drug</h2>
<p>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 &#8211; it is terrible business practice.</p>
<p>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&#8217;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.</p>
<p>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.</p>
<h2>Writing “Closing Code” is unlikely to be profitable</h2>
<p>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.</p>
<p>The problem, like many things that are not good for us in the long run, is the first time doesn&#8217;t hurt in an obvious way. A strategic product initiative gets delayed by a couple of sprints, the impact isn&#8217;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.</p>
<p>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.</p>
<p>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 <a href="https://www.mindtheproduct.com/the-balanced-scorecard-a-framework-that-drives-impact/" target="_blank" rel="noopener">CAC (customer acquisition costs)</a> 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.</p>
<p>“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.</p>
<p>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.</p>
<h2>Strategic product initiatives can make or break next year</h2>
<p>As the company year approaches the end, next year&#8217;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&#8217;t delivered the strategic dependencies for growth. This is painful and regularly sees product leaders leave the employer.</p>
<p>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.</p>
<p>This is how the drug of “Closing Code” kills growth and eventually destroys the potential for a company to scale.</p>
<h2>How to avoid “Closing Code”.</h2>
<p><a href="https://www.mindtheproduct.com/innovating-in-leadership-with-janice-fraser/" target="_blank" rel="noopener">As product leaders</a>, 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:</p>
<ul>
<li>Focus on transparency of development costs,</li>
<li>Share feature adoption,</li>
<li>Reframe the question from “shall we build x”, to “shall we delay this strategic initiaitive”,</li>
<li>Have roadmaps with limited spots for content, ie swapping things out on the roadmap never adding.</li>
<li>Share customer evidence and soundbytes to inform decisions,</li>
<li>Log key decisions in your lightweight governance process.</li>
</ul>
<p>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.</p>
<p>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.</p>
<p>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 <span style="text-decoration: underline;"><a href="https://www.righttoleft.io/blog/how-to-execute-your-product-strategy">https://www.righttoleft.io/blog/how-to-execute-your-product-strategy</a></span>.</p>
<p>&nbsp;</p>
<p>&nbsp;</p>

core/freeform

A year with ChatGPT and product innovation: Navigating the AI landscape

Mastering perspective – zoom in, zoom out as a product leader by Navya Rehani Gupta

Modern-day leadership by Janice Fraser

Master the art of leading through influence by Shyvee Shi

Is your innovation project on track? by Tendayi Viki

Finding your frosting as a product leader by Jeff Birkeland

Learnings from London: The secret sauce to hiring great product people by Kate Leto

Product leadership in a chaotic world: Balancing short-term and long-term goals

Dave Martin

Read more

Comments