Success relies on the organisation being able to leverage some core set of capabilities. Often those capabilities are made up of data, software and business logic and can be thought of as products themselves.
Borrowing from Elon Musk—who refers to the Tesla factory as “the machine that builds the machine”—we might refer to the software and the data within an organisation as “the products that deliver the product”.
To understand why these “products that deliver the product” are so important, we can look to Amazon. In Bezos’s 2015 Letter to Shareholders he describes a small team launching its one-hour delivery service Prime Now, “in only 111 days after it was dreamed up”. In that letter he describes what the Prime Now team prioritised in that aggressively short delivery window.
Unsurprisingly, the Prime Now team invested time in building “a customer-facing app” but, notably, they also “tested, iterated, designed new software for internal use – both a warehouse management system and a driver-facing app”. Many things would have been deprioritised for that first three-month delivery window but not those two internal systems (or products), integral as they were to the successful launch of Prime Now.
Which is to say, “internal digital products” matter.
In this post, I want to explore further this important category of digital products and share some common pitfalls that I’ve observed in my consulting practice, as well as some solutions to help internal products succeed.
Definitions & Characteristics
First let’s have a crack at a workable definition. We might say an internal digital product aims to achieve one or more of the following
- Enable people across the organisation with decisioning.
Examples: product/marketing analytics platform, marketing analytics, or Dashboards and Visualisations
- Enabling daily operational needs of the business (in say Digital Marketing or Sales)
Examples; Customer Data Platform, Warehouse Management System, CRM - Enabling the organisation’s core product(s)
Examples; product catalogue APIs, Ecommerce platform
In this definition I include both “Data Products”, as well as “regular” digital products, such as a CRM.
The Problem
What I’m observing is that when it comes to internal digital products, something’s amiss. Products of this nature seem to fail more often. I’ll give three examples I’ve been witness to:
- Recently on a call about a data platform, the conversation emphasised how this organisation had been down this road before and “failed spectacularly” to get it off the ground. “Requirements just kept getting added!!”.
(Notably, at the end of that call, I was no clearer on the purpose of the data platform) - On a recent engagement, in the 18 months we were there (doing other things), we witnessed the ecommerce system get replatformed twice, in quick succession, at significant expense. The second replatforming was deemed necessary to undo the friction, complexity and costs introduced by the first.
- Some time ago I witnessed the implementation of SalesForce Marketing Cloud. Despite the platform’s considerable power, the project delivered limited value to the digital marketers due to poor implementation decisions made with little-to-no consultation with the end users.
It’s not just me. In this HBR article, the authors reference a “large Asia pacific bank” grappling with an internal digital product:
“It launched a massive program to build pipelines to extract all the data in its systems, clean it, and aggregate it in a data lake in the cloud, without taking much time up front to align its efforts with business use cases. After spending nearly three years to create a new platform, the bank found that only some users, such as those seeking raw historical data for ad hoc analysis, could easily use it. In addition, the critical architectural needs of many potential applications, such as real-time data feeds for personalized customer offerings, had been overlooked. As a result the program didn’t generate much value for the firm.”
Each of these companies are successful businesses with successful customer-facing products. But the common thread here is less than ideal outcomes with their Internal Digital Products.
What’s going on here?
I have a very simple hypothesis as to what might be going on. There is a lack of basic product rigour in creating internal digital products that we otherwise would bring when we build digital products that customers pay for.
I say basic product rigour because I acknowledge teams may not have the luxury of bringing the same degree of product rigour to an internal digital product as they would a product customers pay for. Nor would that necessarily make commercial sense.
But what I’m seeing is, at times, a near void of product discipline. For instance, it’s common to see a lot of rigour around the prioritisation and delivery of an internal product (When can the team commence the initiative? How long can we expect it to take?). Whilst at the same time seeing little to no validation rigour (Should we build this product and for whom? What parts of the product are the highest priority?, Will the target audience choose this product to complete their job-to-be-done?).
Similarly, vague mandates for a Shiny New Data ThingTM (a lakehouse, AI, or worse yet “a data platform”) solving ill-defined customer and business problems aren’t at all uncommon. In the time it’s taken me to write this blog post I’ve had two conversations with two separate prospective clients exhibiting exactly this behaviour.
Let’s unpack this a bit further and look at some common pitfalls that I believe lie at the heart of this conundrum:
- We think data is different; your adaptive way of working doesn’t work here
Often an internal digital product is very data centric. It might be for instance, a Large Language Model that transcribes customer service conversations.Applying adaptive ways of working—be it scrum or kanban for instance—to these types of products (vs say a more conventional digital product like a B2C mobile app), is not always straightforward and not always something those teams are experienced in.
This may result in a misguided, if unspoken and perhaps unconscious, sense that those adaptive ways of working don’t apply in internal product situations.
- We are too easily beguiled by new technology
It’s very easy to be beguiled by new tech, particularly when there aren’t demanding, paying customers keeping us honest. This is possibly compounded by the fact that the high-volume and high-frequency of new technology is causing some technologists to feel overwhelmed. Matt Turck, author of the annual MAD Landscape, drives the point home nicely with this tweet.
- We obsess over outputs but not over outcomes
John Cutler describes this neatly as “Success theatre around shipping with little discussion around impact.”
It’s all very well to move the “The Google Analytics implementation” card to Done. But what did it achieve? Does the marketing team still need to cobble together 15 spreadsheets every Monday to identify their best performing acquisition coupons or can they self-serve that now from GA? - We are talking to customer proxies not actual customers
Talking to customers is widely accepted product management wisdom. Yet how readily we seem to forget this when building a product for internal use. I suspect this might be happening because it’s easier to justify substituting talking to a customer with talking to a customer proxy when the customers are your colleagues. Something akin to: “I haven’t been talking to the customer support team regularly but I know them and I think I know what they need”.
In aggregate, these pitfalls conspire and compound together. Culminating in a greater tolerance if not acceptance of the ineffectual product delivery habits of yesterday; when we shipped in big batches and didn’t validate our assumptions about what customers need. When we obsessed over technical risk but paid little to no attention to value risk (whether users will choose it) or usability risk (whether users can figure out how to use it).
What to do about it
In the aforementioned HBR article they state: “We find that companies are most successful when they treat data like a product.” So it is, in our experience, with internal digital products.
To that end, here are some actionable nudges that we recommend you experiment with on your next internal facing product.
- Obsess less over the solution and more on the problems
Build a habit around talking about the problems you’re solving, not the platform you’re building. Why? Because your customers don’t care about your platform or your algorithm.Good product managers do this effortlessly. But we should be bringing the customer problems into the team’s daily conversations, regardless of whether the initiative has a dedicated product manager or not.
Problem statements are a good starting point here. Properly framed, the problem statement will aid clarity, scope and alignment and crucially put the customer at the centre of your discussions.
- Solve problems through customer collaboration
To quote Jason Yip, “As much as possible, developers should collaborate directly with the people that have the problem and be provided the context and support to be effective in doing so.”Example: at Quitelike we were challenged to help the business solve some challenges with calculating and reporting on GST.
The way we solved the problem was deeply collaborative. We worked closely with the main stakeholder, the CFO, sharing and adapting our solution in short iterations until it met his immediate needs.
- Celebrate outcomes not output
As Cutler hints, you are what you celebrate. So at the next showcase, instead of celebrating the completion of the Google Analytics implementation, celebrate the fact you’ve just saved the marketing team a whole lot of manual effort each work in completing one of their jobs-to-be-done. - Optimise for speed-to-value
Don’t succumb to the hoary old claim of “doing it once and doing it properly”. Optimise for fast feedback with regular releases to *actual* customers. This isn’t a capitulation to building a lesser product. To the contrary. As Allen Hollub so eloquently put it: “Paradoxically, trading perfection for fast feedback usually gets us closer to perfection”. - Recognise you’re building a product
Finally, recognise that what you’re building is a product. Your CRM is a product. Your warehouse management system is a product. Your product recommendations algorithm is a product. Your BI/Dashboards are a product. They are not platforms with faceless users. They are products with real customers who have real wants, real needs and real jobs to be done.
I also would recommend listening to the DiUS lunch and learn on the topic of data activation. The panel conversation also offers tips on how to get closer to your (data) products and users, suggesting that you start by asking what questions you need to answer with your data.
Internal digital products matter because these are the products that build the product your customers pay for. They are therefore deserving of the benefit of some of the basic product discipline and practices we know to be effective in delivering high-value, high-impact products expediently and cost effectively.