Back to the Origin: Navigating the Pivot from Retail to Curated Marketplace for Scalable Success

Welcome back. I hope you're all suited, fed, and watered. Before I get started, I’m sure some of my colleagues in the audience will attest to this: I love a fact. I wanted to share a fact that I recently found out—purple doesn’t exist. Apparently, there are no purple photons, and what your brain does is just make up the color to represent a lack of green light. I found this out after I put this deck together, so you’re about to enjoy quite a lot of “not green.”
I lead technology at Not on the High Street, a UK-based marketplace that’s home to over 5,000 small brands. I’ve been with the business almost exactly two years, and in that time, we’ve gone through quite a lot of change. The premise of what I wanted to talk to you about is why that change is important and how we’ve navigated the shift at the same time as fixing our approach to technical product delivery.
But first, a little introduction to me. My background is in software engineering, and I started my career in agency land. I moved to DTC e-commerce and retail, with a few stops at comparison tech and insurance. And, as Chris mentioned earlier, I can attest—insurance is helping teams connect the big picture to the tiniest details in order for them to deliver greater value, regardless of the business context. That has been a primary focus of mine, and in joining the Not on the High Street team, this was exactly the challenge.
To get us started, I wanted to share a quick three-minute video. Most people in the UK have heard of Not on the High Street in some way, shape, or form. We’ve been around since 2006 and broadly offered the same value proposition. However, what tends to get lost is why we do what we do. In this short video, you’ll hear from Leanne, our CEO, and some of our partners talking about Not on the High Street in a way we haven’t much in the past. Leanne’s in the audience, so if you spot her afterward, say hi.
So what doesn’t come across fully from that video is the sheer level of curation and hands-on partnership that we offer to our partners. One of the sections I unfortunately cut out of that video for time was one of our partners talking about one of their bestselling products and how the idea for that product came from a Not on the High Street partner development manager, and how the product was developed with them.
Not on the High Street’s purpose of championing, supporting, and elevating small brands has historically been overshadowed by playing in an online retail world. This has driven a more purposeful shift internally to play to our strengths. We’ve always been an online marketplace by definition. However, the key differentiator that separates us from other marketplaces is the nature of the partnership that we offer and our curation principles to ensure quality, trust, and to bring the best small brands to a wider audience.
So why is it that I’m stood here talking to you about a pivot from DTC retail to marketplace? Well, there’s an inescapable, simplistic truth that needs to be said: businesses exist to generate money. They may have a purpose or a mission, but this really just defines how that money is spent. For everyone employed by the business, there’s only three categories of work to consider: you have to make money, you have to not spend it all, and you have to protect what you keep. It’s no more complicated than that.
The money generation happens for us when we sell things online, and we got good at it. So we did more. Very soon, most of the business operations looked much like a DTC retailer, without the usual supply chain. However, without a specific purpose or mission to steer how that money is spent, we continued to operate like a DTC retailer. This has a profound effect on the work that people do.
Now, I’m only here to talk to you about how technology and products have been affected by this. But as an online marketplace, the technical products we produce are the epicenter of our business. Our e-commerce focus for many years has meant we have underinvested in the areas that make us a marketplace.
The first step in the journey for us was obviously being more purposeful in our mission. We’re a conscious, curated marketplace of inspirational finds from trusted small brands. However, it’s the specific meaning behind some of these key words in that mission that we wanted to give absolute clarity on. Words like “conscious,” “curated,” “inspirational,” and “trusted” can all have ambiguity and relativity in their meaning. So it’s super important to clearly define what you mean in using these words to help steer a pivot.
This, paired with our positioning as neither 100% DTC retailer nor pure-play online marketplace, has given us the basis for much more honest conversations about what we should and shouldn’t be doing as an organization—from the way that we prioritize to our definition of a customer and the things we need to fix.
Now, when I joined the organization two years ago, there were a number of compounded symptoms of this lack of clarity and direction that needed attention upfront. When I first met our investors, I was told that the team was slow to deliver value and they wanted things to move faster. That’s usually investor-speak. But when I asked why, there were a mix of answers, ranging from guesses, “I thinks,” and a few shrugged shoulders. Not a unique problem by any stretch, but one that proved much bigger than I had expected.
In the first two weeks, we ran a large number of discovery workshops and sessions to try and get to the bottom of the issue. It turned out to be much more like a therapy session, and I really hadn’t banked on the litany of woes that I got back. In one way, this was really good—I had stuff to work with—but my inner monologue, and sometimes my outer one, asked this quite a lot: “What have I got myself into?”
From the discovery sessions, what was crystal clear was the sheer size of the divide between technology and the business. There was even a sizable divide between product and engineering. The engineering team had been wrapped in cotton wool and put on a pedestal, shielded from the realities of the business. Multiplied by a lack of clear identity and mission, it gave way to a “never-question-an-engineer” culture. The resulting team continued to grow apart from the state of the market and our purpose as a business.
The result? We were building and maintaining too much—and the wrong stuff. Eighteen years of this mindset has, unsurprisingly, led to a hugely oversized and overcomplicated platform that’s now an anchor to progress. And all of this became a distraction from what really mattered. Everyone across the business became frustrated.
A lack of strategy and acknowledgment of the problem is a big contributing factor to this. But in reality, the age-old, output-based mentality and doing too much stuff really led to the teams closing themselves off and doing what they thought was right. This has been a key issue for us to fix, but it has also been a really great opportunity for change.
Now, I’m hoping I don’t need to define what a customer is to this room, but a big part of our pivot has been being purposeful about the definitions that we have. We have always defined customers and partners separately. That’s not inherently a bad thing, but this has caused us to focus on one or the other. Looking back to our DTC ways of operating, the ones that bought from us always won focus. Again, not necessarily a bad thing, but one that’s led us to not focus enough on the ones that sell their products on the platform and, arguably, the ones that make us our money.
So, in being more customer-driven, it’s been extremely important we see both consumers of Not on the High Street’s services as customers—paying customers—and partners. This is more than simply changing a definition. It shifts the metrics and outcomes we go after, and it opens up a whole new set of B2B-to-C metrics in the way that we strategically and financially plan.
The shift in focus to include meaningful investments in the systems, tools, and products that help our partners to sell more and sell better is the foothold to the pivot. Without it, we continue to focus on only e-commerce outcomes and metrics, and our technology and product strategy follow suit.
An early change that we put in place was to re-architect both the teams and domains. For those that are familiar with Conway’s Law, this is a classic reverse Conway maneuver: organize the teams and work boundaries to drive the system architecture that you want to see. Previously to this, the teams were service-oriented, not customer-focused, and the dependencies between the teams were vast. More importantly, partner concerns and customer concerns were completely separate.
Today, we have a load of architecture that’s disconnected from one or the other of the consumers of our services. The main thinking here was to make the domain definitions purposely wide and customer-centric, bringing in deep slices of software that are needed to operate the domain, and then build cross-skilled delivery teams around the requirements of the domain—software languages, specialisms, etc. It’s not perfect by any stretch and something that we’re continually inspecting, but this represents a fundamental shift in the way that the teams organize themselves around our products and has facilitated a greater focus on the consumers of our services.
The bigger challenge for us is thinking cross-functionally, but that’s something that we’re working hard to understand at the moment.
Now, earlier, I mentioned that as a result of an engineering-focused mindset, we have a hugely oversized and overcomplicated platform, and that in the reorganization of the domains, we purposely made the domain definition and surface area of responsibility wide for teams. Well, these two things result in a lot of stuff for teams to manage, and we’ll continue to spend too much money on the things that aren’t valuable to our customers if we don’t address prioritization.
And never fool yourself into thinking it will get easier to prioritize just because you have a clearer mission or purpose, especially when there’s a disconnect between engineering priorities, business priorities, and the customer ones.
So with that, I introduce the highly scientific triangle of “Things Tech Gives a Sh*t About” and the inescapable problem in technical product development: balance between new investments and keeping the existing software functional and healthy. The triangle represents three core elements that are usually on tech and product teams’ minds, and typically, only one of these elements features on the radar of the rest of the business. As a result, it’s usually the only one that receives any financial value.
So what happens when the business is focused solely on customer value and has no concept or mental model for the other two elements? Well, the triangle breaks apart, and one of two things happens:

1. Debt management efforts and the health of the delivery process catch fire—which feels okay in the short term because you’re delivering what the business thinks it wants, and people are happy. But it’s short-lived, and it very quickly bites you. Your roadmaps become entirely about managing complexity, unplanned work, and interruptions, and maybe a tiny bit of existing capability enhancement—but very little customer value.
   Or:
2. Teams hyper-fixate on tech debt management and engineering health and separate themselves from product and customer value. This feels okay to engineers and can be useful in short bursts, but ultimately alienates the whole department from the business. The value of capable product managers and engineers gets called into question because you end up spending far too much time and money on things most of the business doesn’t understand—and engineers are terrible at explaining. Yet again, customer value suffers.
   This is closer to what had happened at Not on the High Street. But, somewhat impressively, we managed to do both simultaneously.
   The interaction across all three elements is what’s fundamental to achieving some form of balance in sustainable technical product development. However, when teams first try to balance the work, it usually ends up being a prioritization call between two-thirds of the work that the business doesn’t understand and one-third of the work that the business does and believes should be the only work to be done. Inevitably, this doesn’t go well, and more fires ignite. You’ve just delayed the fires a little longer, pretending you’re balancing things. But in reality, you’ve solved nothing.
   In order to really tackle the problem here, you need to reframe the landscape. You need to draw a picture in a way that builds trust with engineers and the business using simplicity and clarity.
   What if the business really understood the jobs to be done and didn’t switch off every time the lead engineer was talking about the next infrastructure migration? And what if engineers had a set of metrics and terminology that helped them to understand their business impact, instead of just the efficacy of their team and process?
   Well, we all love a framework in tech and product, so here’s another: the literally named Balance Framework. It’s pretty simple. Initiatives, epics, bugs, stories, tasks—these can all be categorized in one of four ways. Once you’ve categorized the work, you can measure where investments have been placed, and you can see the trends and a story as to why you’re now more than likely just keeping the lights on.
   As you can see, it gives a great basis for talking about work using simplified language that most senior leaders understand and care about. It reframes the interaction between customer value, technical debt management, and engineering health. It enables you to talk about how time invested into productivity pays off down the line, and if you’ve got the measurements right, you’re ready to say exactly when it starts.
   It starts a conversation about further visibility into what goes into keeping the lights on and removes the technology air gap by showing that all of this work makes up a digital product—not just the features. And looking forward, it enables you to help teams make elective investments in a way that works for engineers and product managers but is also understandable for the rest of the business.
   Most importantly, it gives you the connective tissue between the things that actually matter to everyone and gets them all trying to pull in the same direction. Now, we’ve only just started measuring against the framework, and surprise, surprise—we look a bit like this. The interesting thing is that we’ve proven that absolute focus on new things for long periods of time will only ever result in this. And this is not good use of what is usually the most expensive team in most companies.
   The implementation’s been pretty simple. We simply introduced a field into Jira to allow product managers and engineering managers to select a category at a ticket level. Integrated a Jira integration, and a tool does the rest. The harder part is how you use that data and introduce the categories into the planning processes to add a simplified lens on product roadmaps. And there’s usually a cultural change involved, which is really hard but worth the effort.
   Although there’s no ideal state or specific numbers to hit, KT will always take up the large proportion of your time. After all, you have your entire product’s history to maintain. However, overtly committing to chunks of time in your roadmaps to improve productivity in order to decrease cycle time or having an open conversation about the financial outcomes of KT balanced against new things and the connection to company KPIs, goals, and mission breaks down so many barriers to understanding what’s important and valuable to everyone involved. It makes it so much easier to draw connections to the customer value and delivering that value early.
   As with everything in life, this isn’t a silver bullet. But in a quest to help teams understand and navigate a multifaceted problem, in changing our approach, it’s helped to break down barriers with simplicity and it’s drawn connections to the things that everyone cares about. The Balance Framework helped us to understand how to balance the investments we’re making across providing customer value, technical debt management, and engineering health. It gives us a great framework for helping the business to understand the impact of product and technology teams.
   But what it doesn’t do is help us decide on the investments we shouldn’t make. And in a period of change, those are more important. I bet that most of you in this room feel like there’s too much stuff on your roadmaps or trying to get onto your roadmaps, and that no is really hard to make stick. That’s exactly the quandary we’re in, particularly in a pivot to invest more holistically across our dual definition of customer.
   Well, there’s another tool that we’re using to help us out, and again, it’s really simple. If businesses exist to generate money, then all work should fall somewhere on one of two axes. Work should either contribute to the operational performance of the business or should be strategically important and move us toward the company goals or strategy. Now, obviously, if a piece of work ranks highly on both axes, then that’s your core work—things you should absolutely be investing into and a great use of you and your team’s time.
   Conversely, if a piece of work ranks low on both fronts, then obviously, you shouldn’t even be considering it. This is true of both new work but also existing systems, services, and features that you really should remove in order to optimize your operations or your customer experience. We’re currently doing this exact thing. Our platform’s too big and complex, so removing some of the fluff and stuff that actually just slows us down is an important early step.
   The more interesting conversations happen when a piece of work ranks highly on either axis, but not both. There are slightly different definitions to both of these, so it’s key to apply your own context, budgets, and thinking in these decisions.
   If something is high on strategic importance but low on contribution to operational performance, then this is a good opportunity to increase your efficiency as a team or in an existing product to achieve it. Alternatively, partner with an organization that has the capability, rather than overbuild.
   If something is high on contribution to operational performance but not strategically important, then either buy the capability or outsource the effort. Now, life is not as simple as I make out here, but as a technology leader, in whatever capacity, it is so important you have a healthy conversation about this.
   Parkinson’s Law dictates that work will always expand to whatever capacity you give it, so never fool yourself into thinking that you’ll reach a steady pace without this kind of prioritization. What we’ve done historically is fool ourselves into thinking everything is top right. We’ve built literally everything. That’s now manifested as an anchor to progress, and we’re retrospectively admitting that there’s a large amount of stuff that sits bottom left and needs to be unpicked. If you’ve got the luxury of avoiding this bear trap, then do so early on.
   None of this is magic. It’s basically reframing the conversation and giving you a simpler view to have better conversations with people. In navigating a strategic pivot, such as we are, the simplicity and common sense that these represent are bringing people around a common purpose: customer value.
   Despite all of Not on the High Street’s complicated definitions, a complex platform, and a rocky past, engineering and product teams now have frameworks to think about how they spend their time, what they should and shouldn’t care about, and a clearer decision on what they should build versus buy. The business has a better understanding of how technology and product teams operate and has better visibility into the jobs to be done. Trust is built, and people take accountability for the metrics that are actually important to the business, as well as the ones that are important to product and engineering.
   You, as a leader, have built a sustainable approach to empowering teams to build and run the things that matter to your organization and customers—whatever that might be. I couldn’t do this without including that one. So, in navigating the pivot, it really has just been about good, sustainable product development principles and customer-centricity: clearly defining our dual definition of customer, understanding how investing in B2B-to-C systems, tools, and initiatives can be a boomerang to sales and success, and using simplicity and clarity to help the business understand what goes into developing and maintaining technical products.
   Most importantly, it’s been about being absolutely clear on the mission up front. After all, it’s the anchor to everything else that follows. Twenty-five minutes has been quite difficult to get through two years of work, so please do reach out if you’re interested in talking a little bit more. There are some references here about some of the material I’ve talked about and also a link to the longer-form video if anyone’s interested. Thank you very much for your time.
   Moderator: Amazing stuff. We have a few minutes for questions, but I just want to say I loved the aspect you talked about—about that connective tissue between everything. We’re quite good at, as humans, putting things in boxes and not necessarily appreciating how those things kind of connect. And that being, like you said, it isn’t a silver bullet, but it sounds closer to a silver bullet to get people on the same page. Really good stuff. We have one question currently—get typing away, everyone.
   You’re in the middle of the process. Are you on the right path? How do you know?
   **Dan: **This is from our CFO, isn’t it? It’s a really good question. I think for me, it’s always been around identifying the problems and the root causes. I think one of the things that we’re kind of—well, I’m trying to help people to kind of focus in on—is identifying what are the problems that hold us back.
   As I mentioned, the technical complexity, platform complexity, and the things that are kind of a bit of an anchor to progress are only one factor to some of the other things that we’re doing. But in trying to release customer value, in trying to respond to changes in the market, in all those kinds of things, it’s proving to be something that really slows us down and we can’t react as quick.
   So, I’ve just seen the other one. That’s a good question. I think making sure you’re on the right path really comes down to tying it back, that red thread, all the way back to the problems that you set out to achieve in the first place.
   Something I didn’t really cover in this is being absolutely clear up front about what problems it is you want to solve. Because in any business, you could probably write a long list of problems that you want to solve. And coming back to that prioritization point, you have to prioritize the biggest problems. With us, with private equity backing, talking to our investors, and trying to identify what problems they want to try and solve, and also helping them to prioritize and understand that we can’t do everything at once.
   Moderator:Very nice. Here we go. I’ve suggested—or, oh, what are we going for next? All right, we’ll go for it. The existential question. Let’s talk about it in the context of your work and in the context of your organization. Why can’t we all just learn to live together?
   Dan: I don’t know. I can’t quite work that one out. That seems fair. I think—guess that’s one of my colleagues pranking me. I think what’s behind that is the kind of problem that we’re trying to solve. As I said, when I joined the business, the gap between technology, the business, and our purpose was so vast that actually everything I’ve just talked about has been tools and mechanisms to try and help people live together a bit more.
   At the end of the day, that piece around businesses exist to generate money is simplistic, but when I was talking to particularly the technology and product teams and bringing that element of commerciality in, it’s finding that balance. You’re building products that not only contribute to the success and revenue of the business but also need to answer your customer problems.