PRODUCTHEAD: Should you do custom features for paying clients?

pulk/pull revolving products #

every PRODUCTHEAD edition is online for you to refer back to

---

tl;dr

Product models are more scalable and have higher investor valuations than service models, but can be more difficult to implement and require a longer sales cycle

If you find your team is biasing towards delivering custom features (= output), refocus on discovery and problem solving instead (= outcomes)

---

hello

Startups often reach a point where a large or influential customer asks them to build custom features into the product in return for hard cash. Is it a good idea to accept?

This situation tends to crop up more in the world of business-to-business (B2B) software. There are often lots of compelling arguments for taking the cash and building the feature:

the payment translates to several additional months of runway for your startup;

you may be under pressure to accept the work if there’s a credible risk the large customer will stop using your product if you choose not to build the feature for them;

you may also reckon that the custom feature may be something you can offer to the rest of your user base.

To a startup with rapidly diminishing runway and no other investment in sight, it’s perfectly easy to understand the attraction of a large company throwing money at you to add features your own product. It may still not be right call to make, though.

Pick a business model and stick to it #

The business model for a company optimised to deliver custom, one-off projects is fundamentally different to that of a company aspiring to sell a standard product repeatedly.

It’s like comparing Olympic gymnasts and weightlifters: they’re both very fit and strong, but they’ve optimised their bodies to work in very different ways. A gymnast is lithe and supple for a range of diverse movements, a weightlifter focuses on a very specific range of movement. Swap roles and the gymnast will not be able to lift as much as the weightlifter, nor the weightlifter to perform cartwheels and tumbles.

Similarly, it’s perfectly possible to optimise your business for custom delivery or product repeatability, but very difficult to excel at both using the same team of people. Where you do see larger companies doing both successfully, they often have completely separate and ring-fenced teams for each specialisation.

If you’re building and selling a standard product to a market segment, then your development costs are fixed: once you’ve broken even, every additional unit you sell is essentially pure profit. You retain responsibility for maintaining the product, but your customers subsidise that work through ongoing subscriptions or equivalent. You want to take valuable new products or features to market as efficiently as possible, so that your product’s break-even point can be reached sooner.

In contrast, custom, one-off work gives you variable costs to deal with: if you want to take on more work, you need more people working in parallel. Thus you want to quote as high a day rate as possible (and then to prolong the work if you’re unscrupulous), or to deliver fixed-fee projects as quickly and efficiently as possible to ensure profitability. Either the customer takes on the responsibility for maintaining the custom software themselves, or they pay your usual (highly profitable) day rate for any additional work later on down the line.

The downsides of mixing your models #

When you accept work to build custom, one-off features in your ‘standard’ product, you essentially incur the downsides of both models without the upsides that comes from optimising your operations one way or the other.

Hard to prioritise: a contractual obligation to a large, paying customer ties your hands on prioritisation — it will always be a higher priority than anything else you’re working on, even if the other product improvements are more broadly applicable and valuable;

Impact on other customers: for the same reason, any delays on the contracted work will almost always steal time away from your development team, causing knock-on delays that will affect your broader user base — delays to your main roadmap may affect customer acquisition, increased time to fix bugs may affect customer retention, meaning your startup will take longer to reach its break-even point.

Control over design: a custom features effectively outsources its design to your customer, who as a general rule will only suggest an incrementally better version of what they’re already familiar with, and likely something specific to their own workflow.

Distraction from product vision: it becomes much harder to work towards your vision when increasing numbers of disparate, one-off, custom features are muddying the coherence of your product — this will also gradually refocus your product away from the needs of a broader user segment to the needs of a handful of large customers.

High relative cost of maintenance: even though only one customer is using a particular custom feature, you still have the burden of maintaining that code base until that customer leaves.

When a company is set up primarily to deliver repeatable product, all of this creates a lot of hidden overheads that detract from the profitability of the custom work and make it far less attractive.

For you this week #

In this week’s PRODUCTHEAD, I’ve pulled together a few great articles that explore this very problem in greater detail.

First off, CEO of ProdPad Janna Bastow breaks down the differing cost models of these two ways of working. She suggests the best way for product companies to avoid this problem, which she calls “the agency trap”, is to focus on discovering and solving problems instead of just churning out features.

Veteran product consultant Rich Mironov describes the challenges of transitioning from a product or service model to the other, and details the downsides of operating a company employing both models at once.

Then author and strategic advisor Melissa Perri describes how to circumvent the problem of contractual obligations driving your product roadmap.

While we’re on the topic, I’ve also included an article I wrote discussing ways to introduce an element of product management into a ‘pure’ agency.

An agency is solely focused on custom work for clients, and so avoids many of the problems of trying to be both models at once, however this also means there’s often little scope for product management. I wrote the article when a product manager who’d joined an agency found themselves only focused on delivering whatever the client wanted, rather than identifying and addressing actual user needs.

Speak to you soon,

Jock

---

---

what to think about this week

Avoiding the agency trap — product led companies scale-up

As a product person, you should cherish every moment you get to spend in discovery mode. This is where the big, juicy problems of the world are found and cracked, and real value is discovered.

Delivery is when you’re honing in on that one problem, and is really more of a means to an end. You have to have delivery, as it ultimately pays the bills, but it’s not the earth-moving disruptive activity that discovery has the potential to be.

You have to have balance

[Janna Bastow / ProdPad]

Product models, service models, and investor valuations

Almost every week, I have a conversation with executives at B2B software companies who don’t see a bright-line distinction between software license revenue and customization/implementation revenue. Or why this distinction is essential to their investors. But when I do product due diligence for SaaS-focused PE/VC firms, it’s the very first thing I look at. Let’s walk through my concern and illustrate it with some simplified investment outcomes.

A frictionless product approach is more attractive to investors

[Rich Mironov / Mironov Consulting]

---

---

Getting sales + product in sync

I once joined a B2B company as a Product Manager in the the middle of the year, so their entire product roadmap was set and in motion. My team was responsible for building a feature that I quickly realized did not align with our strategic initiative for the product. I questioned the purpose of this feature, and was met with the worst possible answer: “Oh, well the sales team promised it to one of our big customers, and they’ve already included it in their signed contract.” So we had to build it, and we had to build it fast, as the deadline was looming.

Don’t compensate for contracts closed

[Melissa Perri]

The agency trap

How can product management fit into an agency business model when requirements or specifications are often contractually set in stone by the client up-front?

Spoiler alert: not easily

[Jock Busuttil / I Manage Products]

recent posts

Getting your first job as a product manager

Job adverts present a chicken-and-egg problem: they all need you to have product management experience to secure a job, but you don’t yet have a product management job to gain that experience.

Don’t let this discourage you!

Practical tips for breaking into a career in product management

[I Manage Products]

Force multipliers

Recently I was explaining to a client why I focus my efforts on finding “force multipliers”. These are what I call activities that allow us to extract multiple benefits from a single piece of work. You could think of it a little like a workplace fusion reaction, where the output ends up far greater than the input effort.

Getting more out than you put in

[I Manage Products]

How to sharpen up your vision and strategy

When the vision and strategy are focused and clear, they allow product managers to prioritise and filter the possible options for their products more easily.

Use these straightforward questions and worked examples

[I Manage Products]

PRODUCTHEAD is a newsletter for product people of all varieties, and is lovingly crafted from ratcheting strap clamps.