Lean development of backend, non-customer facing products

Delivering real and direct incremental value to end-customers is the cornerstone of lean and agile product development. It is the secret sauce for quickly entering a product development feedback loop, failing forward and iterating on your ideas toward product-market fit.

But what about when the ‘product’ you’re working on is within a large business and the improvements you make are not directly surfaced to the customers the broader business is targeting? The standout example of this is building the backend platform of a marketplace when the company is not the owner of the inventory (think eBay, Amazon, Uber, Skyscanner, Trip.com, Airbnb, etc).

Frontend clients (e.g. app and web) can deliver incremental, direct value to customers with UX changes and new interactive features. Supply-side integration teams (e.g. connectors to partner APIs, tooling for self-integration of supply into your marketplace, etc) can deliver incremental value to customers by providing greater inventory to meet customer needs. Essentially these teams can impact direct end-customer facing metrics — the volume of customers inbound and the conversion of such volume through your funnel.

However, as the platform between these two ends you can’t exactly deliver direct and incremental customer value in the same way. Any work you do that could deliver real value must be passed on through either the frontend clients or supply-side integration teams’ stacks first. There is a layer of abstraction on all sides between the work you do and delivering end-customer value.

Who really are your customers?

The business metrics your company focuses on may well be end-customer value-based — and for good reason. If you gradually increase the value that end-customers derive from your product, that’s a direct feeder into company growth, retention, and in the end – revenue and profit.

However, for backend products without direct exposure to end-customers, shoehorning your goals and metrics into end-customer value delivery targets feels like a load of semantics and management speak. It doesn’t facilitate incremental progress, people secretly see through the BS, and it doesn’t give good, clear direction for your team to deliver value within the remit they have in front of them. It’s unfair on the team to expect delivery of end-customer value when they don’t have the ability to directly impact these metrics.

So what to do?

In the case of developing a backend platform, in my experience it’s been very useful to frame and treat your frontend clients and supply-side integration teams as if they’re your end-customers. Dig deep into their problems and workarounds, understand their needs and goals, get real investment from them into your solutions, make reasonable tradeoffs based on timeline alignment and ROI, and so on – all the same as if they’re potential paying end-customers.

If you empower a frontend client to implement a new feature they couldn’t implement otherwise, that’s a win for you. If you reduce supply-side integration time, that’s a win for you. If you build data microservices that can be used by additional stakeholders around the business, that’s a win for you. If you make your platform frontend client-agnostic, that’s a win for you. If you surface data to frontend clients faster, empowering them to surface that to end-customers faster, that’s a win for you. The list goes on and on.

The common thread through these examples is that they’re all actually only providing value to backend consumers – not end-customers. Deeply understanding your backend consumers’ needs and tackling them in a prioritised and timeline-aligned manner is the best way to ensure they’re really invested into passing your improvements onto real end-customers. That’s how backend products can deliver end-customer value.

It’s when you say the work you’re doing in the platform is clearly and directly serving or aiming to serve the end-customers that it feels hollow. Give the team metrics and success criteria that they can own and influence, not ones that have huge dependencies on others.

System performance metrics are only one aspect of a great platform

System performance metrics are the closest you’ll find to direct customer-facing benefits without shoehorning. That said, know that the effect of performance improvements on moving customer value metrics will be noisy and diluted by the differing client implementations of that value. For example, you might be able to surface data to frontend clients very quickly, but ultimately it’s up to them when and how they actually surface that data to end-customers.

Moreover, there are many other important facets of a great platform that are neglected if you only set system performance metrics as the goals. It’s fundamental that you don’t ignore the serious benefits that come from improvements you can’t exactly put an end-customer metric to. Examples include modularity of surfacing data, flexibility of the data provided, asynchronous and real time update capability, frontend client and data source-agnosticism, architectural simplicity, configurability, and so on.

If you’re aiming to build a great non-customer facing backend product, you need to think about more than performance alone. By framing your thinking as having your backend consumers as your end-customers, you empower your team to truly think creatively about the materials they have in front of them. It will maximise value delivered through the full architecture chain, which if prioritised and aligned well will translate to significant end-customer value.

Be ready for timeline and alignment frustration

Recognise that as a backend platform, you are the plumber between two ends that have different incentives. It is likely that the metrics of frontend clients mainly care about interaction specifics with end-customers (i.e. funnel conversion), while supply mainly cares about maximising the inventory available to the end-customers (i.e. volume into the funnel). Both sides are extremely important to a healthy and growing marketplace flywheel, but there are definitely frictions, tradeoffs and compromises between these incentives as you dig deeper and embark on a platform-building journey.

Connecting the two ends at a product and technical level is your job as the platform, which can often feel like getting pulled in two directions. Compromises will need to be made, timelines will fall through, the frontend clients’ needs may change based on new strategy, supply may have urgent needs to integrate essential inventory with massive potential benefits, standardisations may simply not be agreed or possible, and sometimes the most beneficial things you can do for clients or supply might simply not be something that they can pass on to end-customers for a frustratingly long amount of time.

Ultimately though, it’s important to remember that frontend clients and supply integration teams are all also trying to deliver incremental value to positively impact their own goal metrics. Moreover, because they have the direct end-customer value card in their back pockets, it can sometimes feel like in terms of company priorities their goals trump yours. It can be frustrating, but if you keep the mindset of clients and supply being your most direct customers, facilitating their needs and goals should feel aligned with your aspirations as the platform.

The one caveat is to make sure you are the voice of longer-term overall architecture health and flywheel balance. You must ensure you are negotiating with each side reasonably and standing your ground with fair and solid platform integrity principles. It’s your responsibility to attempt to maintain a healthy marketplace flywheel balance — to not lean too much toward one side (whether client or supply) as in the long term this one-sided debt will eventually stagnate both sides’ ability to make progress.

To summarise some key learnings

• Deeply understand your backend product consumers’ problems, needs, goals and timelines as if they are your direct end-customers
• Success metrics and criteria for backend, non-customer facing products should be reasonable considering the remit that the teams building these products can directly impact, not wholly dependent on consumers passing on benefits to end-customers
• Recognise the differing backend product consumers’ incentives, and balance and negotiate the varying needs and goals of these consumers in building your backend product
• Enabling your backend consumers to achieve their goals in a healthy and balanced way is a huge backend product success that is worth celebrating