Written by Joel Ippoliti, Chief Product Officer at Seedrs. Following years of experience at companies such as EMI Music, The Guardian, Camelot, Money Advice Service and IBM, Joel shares the key lessons he’s learnt along the way.

There is no single hard and fast rule to follow when scaling your product (unfortunately). Products are as unique as the market context in which they operate; they are the result of a set of complex ‘system’ interactions, and any part of the system may be driving it forward or holding it back.

Every product is at a certain stage of development, has certain capabilities building it (people skills, expertise, processes), sits within a particular company culture, on a technology stack, and is servicing a unique set of customers with unique behaviours and expectations. Every product is a function of these factors, internal and external, and to scale them, you must first understand these dynamics and their interplay – the system that built it. Each part needs to be considered as you scale, and crucially, choosing which to enhance and which to minimise.

Complexities acknowledged, when scaling any product, there are common themes or recurring identifiable patterns. This article is written from a practitioners perspective, highlighting and lightly exploring two common themes: when and what to scale. I’ll bring them to life by drawing on my current obsession, scaling Seedrs (an Equity Marketplace for private companies) while recounting past experiences where I tried, and sometimes failed, to do the same. 

Let’s, therefore, start at the beginning of any product’s journey; is it meeting the needs of customers, and are they willing to pay (or spend time engaging) to have those needs met? Is there a product/solution fit?

Scaling is a Dial, Not a Switch

From the very moment you start testing your proposition and receiving feedback you are looking for the confidence to commit to a set of MVP features, and you are looking to de-risk that investment against potential failure – and, in a way, you are thinking about scaling. This continuous test and learn cycle involving inputs and outputs and the corresponding readjustment – is one that continues, at least from my experience, throughout the maturing of a proposition and continues well into the growth phase.  

Do you have evidence that there is a large enough group of people willing to pay for your service to afford it to scale? Of course, if you are still at this stage, you don’t want to invest too much before you gain feedback that your attempts to expand are working (or not). You’ll need to keep your ‘scaling’ activity in a test and learn phase… Not all things will work the first time, and it will take a bit of effort to find the right thing to do. 

If you think you need to scale to prove there is a market fit (i.e. your idea only works at scale), you’ll need to find a different way – if your vision is serving all things to all people, starting there is tough (pretty much impossible). It requires great focus and restraint to get there as the learnings and evidence come in. Everyone wants to scale, but it is about: a) knowing when you have something and b) when that thing is ready to be replicated en masse.

Of course, before you get to this point, the highest priority to solve is finding a market fit and an operation that can profitably service it. Invariably, as you get closer, your ambition changes, the market reacts to your moves, partners and investors distract you, and you can lose it again. In practice, scaling isn’t a switch you turn on or off; it’s more akin to dial that you turn up and down. You just need to figure out when you should be at 1 and when to be at 11 – and every point in between.


Scale too quickly, and you risk running out of cash. Scale too late, and you may miss the market opportunity or open the market to competitors – there’s a balance to strike. A topical example is Thomas Cook: the Insitute of Directors has blamed its downfall on taking on too much debt to fund rapid expansion, which left it extremely exposed to adverse external market factors, which you can read more about here.

Case Study

Initially, as a product consultant and then later as a non-executive director at a start-up serving ‘enriched’ digital sheet music, we launched our first app into China. The market potential was huge, and our app, which was endorsed by a world-famous pianist, had 80K downloads in two weeks, and it was featured in the AppStore. Frankly, we thought we validated the idea first time out – our MVP proved the case. We felt now was the time to go 9 on the dial.

We spent the next three years building backend processes and tools to ingest publisher content; we switched up our proposition to align it with the much grander vision of the founder, we hired marketers to get the word out and partnered extensively. 

Our ambition widened, and we added great breadth and depth to the proposition. But, in the end, we killed it.

Buoyed by our early success, we failed to appreciate (capture and replicate) what exactly was responsible for that early success. In fact, after the initial app’s success, we launched a different app and tried to disown the early version as we weren’t proud of it. We changed it up so much that we ended up going back to square one – we lost our product/solution fit – we didn’t realise it – but we scaled it anyway. We ended up with a beautiful app that our partners loved, a huge amount of content, and an easy process to onboard that content, but an app that ultimately had limited appeal, and most customers weren’t willing to pay for it. 

We scaled the content and the supply, we stocked the shelves high because we thought that’s what we needed to compete (more content was the key to more customers), but on that route, we didn’t listen to the signs that something more fundamental was afoot. We flicked a switch when we should’ve been turning a dial and maintaining our discipline; instead, we actively ignored the signs buoyed by our early (false) validation.

The Seedrs Case

Seedrs receives 1000’s of applications per month from businesses wanting to raise capital. 1000’s of new investors come to the site every month to invest in businesses they believe in. We receive feedback regularly from entrepreneur’s that we are solving their problems in a unique way that they can’t find elsewhere (there are very few alternatives) and investors are enjoying access to an asset class not previously open to them (there are no directly comparable alternatives). We have a number of opportunities to diversify our revenue streams, add services, and meet a broader set of needs for our customers – it couldn’t be more different from the example above. One of the most significant opportunities (arguably) right now is just doing what we do today, more efficiently. Are we ready to scale? Yes, but that doesn’t mean turning it up to 11. Scaling for us means sorting out the obvious inefficiencies, and making the model work as hard as it can. We are doing that not by expanding into new markets or building new features, but by embedding intelligence into the systems, automating the manual tasks we know we are repeating and will continue to repeat, scaling the culture, and making sure the brand and its promise are well defined internally and aligned with our overall vision. We are ensuring customers receive the same or better service from us, and preparing ourselves to turn up to 11 should markets open due to regulation or change. Basically, optimising the internal and readying for an external market context change to pounce on our opportunity.

Key Learning

  • Maintain a test and learn mindset beyond your MVP validation phase and into your growth/scale phase. Adjust as you go based on the feedback you receive – don’t go to 11 and put your head in the sand!
  • You can’t scale an early proposition without a clear indication of what is working and what is not. Identify the ‘core’ parts of the product – make sure the architecture responsible for making them work is in place, don’t overstretch and disrupt it too quickly, keep focused.
  • The more features you add, the more maintenance you burden yourself with, the more complex the ‘architecture’ you are trying to scale – only do so if you can back it up with a sustainable revenue model.

Optimise (Depth) or Build (Breadth)?

Assuming you have got past that point of optimising the existing and finding efficiencies, should you start to ‘scale’ the breadth of needs you service (the share of wallet for example) or scale the number of people you serve (the number of wallets)? When is enough of one, enough? 

If we think of scaling as about realising efficiencies through volume, then scaling an ‘inefficient’ proposition doesn’t make sense. I can’t help but think of Spotify here but I could equally cite a number of high profile others (Uber, Tesla, WeWork – for more information, read here). So, what is happening in these cases? During my time working for EMI Music, I remember seeing Spotify coming into broker deals for rights distribution on their platform. Those agreements, heavily in the music business’ favour, means that distributing rights-based content will always struggle to turn a profit for Spotify. Scaling this then means finding more customers to pay more for less, and they need to do this by finding the ‘less engaged’ music listener, and they may do this partly by diversifying into other audio content which attracts ‘less cost’ (here is a good article on that). 

So, imagine trying to scale this proposition without a unit metric that scales? There must be some other ‘sell’ to their funding partners, and clearly, there is. Scaling inefficiencies makes no sense unless the size of the prize is so massive, and the user uptake in the meantime is so compelling and the people backing you have enough belief and deep enough pockets to see it through and potentially realise it. From an investor perspective, this even holds true even when valuing a ‘public’ company; you can no longer simply look at the financials (the unit scaling metrics) to determine ‘value’. There is no better indication of this than the consortia formed under the Embankment Project for Inclusive Capitalism which you can find out more about here, which is seeking to attribute value to factors ‘off-balance’ sheet. These factors should all be taken into consideration when scaling.

Regardless of the situation and especially from a product perspective, as you start to attract more users to your service you still must make sure the basics are working, and in a product this means; sign-up, checkout, search, navigate. They are easy to get right (in the context of all the other product problems you’re likely to face (like music discovery for instance) because they are typically universal and there are established norms – don’t try to invent new interactions unless you need to. In the list of problems you’ll need to solve, these will be at the top for solution known, expected outcome known.

At scale, these things will constrain you, and today’s users expect your flows are as good as the market leaders. Surprisingly, and counter to accepted logic, in the early days you will get away with these things being a bit off (not a lot, but a bit). In the early days of scaling your proposition, you are likely to be appealing to super motivated individuals (early adopters), keen to try new things and have a go, even if the experience is sub-optimal. As you try and break out of this market into the early majority (and cross the chasm in between, reference Crossing the Chasm by Geoffrey A. Moore for more on this) – these things become more important. 

If these things are broken, you are making the job twice as hard, but particularly when these inefficiencies are at the bottom of the funnel – checkout is paramount to get right; there is a straight correlation between improvement here and the bottom line. 

Here, again, ‘system’ factors come into play, and it is not always as simple as thinking about a ‘funnel’ and calculating conversion to understand where to optimise or rebuild… Think about your market – in a B2B market you’ll likely get away with a little more in some areas if you understand the dynamics at play, for example: 

Case Study

As a Product Director for a PE-backed, and recently formed conglomerate, selling charts and maritime services, I was responsible for the proposition and strategy for the software used by mariners and sold to fleet managers. The fleet manager (who managed many vessels back ‘on-shore’) purchased software, and one of their main purchasing drivers was a competitive cost/benefit ratio. The onboard navigator (mariner) cared about ease of use, simplicity and features that made their life easier and faster. They cared if something took three clicks vs two to load a new chart and make a purchase. 

Appreciating this dynamic and wanting to scale the service, where do you focus? In actuality, the mariner has no choice; they have to buy the chart using software bought for them by the fleet manager. With the software installed, they have no choice, they need the chart to leave the dock, or the authority keeps them there. Just like shooting fish in a barrel. 

Of course, completely ignoring that poor usability of the software will cause the mariner to complain and that feedback may influence the buyer, but it will be just one input and likely not the primary one (more likely to relate to the efficiency of the route planned). Coupling the onboard software with fleet management software and then building features for the shore-based manager (the one making the purchasing decisions) is more likely to result in growth. For the mariner, it needs to be just ‘good enough’ rather than ‘perfect’. At some point, though, this is short-term thinking as the majority of cost savings are to be found by helping the vessel chart more efficient routes, as fuel takes up the greatest costs. So, if you can build that into your onboard software, great. So, again, this is no simple hard and fast rule – we needed to win right with the fleet manager and solve their core needs in a way they were used to. That got our software onboard, and we wanted to do that at scale. Then, with an installed base, we could layer on value-add features that helped deepen the relationship and take us out of the chart supplier category to the data optimisation partner category.

In B2B, these relationships can be difficult to trade-off against (particularly as a product manager) but necessary – so acknowledge that you need to get to them all at some point, but that prioritisation is key. 

‘Do you go deep or wide when looking to scale’ has no better example than our own local fintech friends, Monzo and Revolut. Do you do the thing that will make you more sales, or the thing that will make you more loved by those that use you? Tom Bloomfield (CEO of Monzo) is clearly thinking about it; here is a recent tweet of his calling out the difference between Revolut’s and Monzo’s strategy:


Clearly, Tom’s point is that ‘Daily actives’ is a measure of success/value, and he has more and there are likely to be unit metrics that back him up on that claim. It’s hard to say looking at this snapshot if that is the most accurate conclusion – we need to understand the rate of acquisition of new customers and speed to convert those into value. Or, if one strategy is to ‘land grab’ and then ‘backfill’, then the rate of ‘backfill’ and the successful conversion thereof.

Do you scale reach, or do you scale breadth/coverage? Go deep and build strong customer relationships and wallet share, or go broad and capture user share? Clearly, that’s a strategy for a time and a place, but it underlines the importance of having a view and knowing where you are with it. Blindingly going after top-line growth numbers (as Tom is intimating) and ignoring underlying commercials may be foolhardy. Blindingly consolidating the product to increase the share of wallet whilst a competitor gets their card in more customer’s hands may, equally, be foolhardy. Of course, neither Tom nor Nikolay (CEO of Revolut) is blind, and they are both pursuing very concerted, and very different scaling strategies.

Every business, at some point, tries to reach out to a new market or segment. It’s a testament to your proposition if you have enough to keep you growing without a fundamental look at your proposition. A key question you must consider: do you stay within the existing segment and expand to new regions (replicate), or do you stay put and find new markets (broaden proposition).

The Seedrs Case

Here at Seedrs, we aren’t just taking an offline model and putting it online – we are inventing a new way of doing things. It hasn’t been done before, and there are few reference points. Our customers are at the forefront – and they are probably at the forefront of a lot of things, they are a certain ‘type’. Most people aren’t like that, and as we grow and expand, we have a real choice – do we stay ‘niche’ and appeal to early adopters, the risk-takers, the lovers of adventure? Or, do we pause and simplify down to cross the chasm to the masses? 

Key Learning

  • Going broad or going deep may be more about a ‘narrative’ than established unit metrics. Establish a scaling narrative, make sure your ‘backers’ buy into it and are prepared to cover your losses as you seek to scale or manage your unit metrics as you seek to break even.
  • In an emerging market where needs are yet to be established, simply having ‘more’ than your competitor is often enough to win a pitch. If you live in this world and you are looking to scale, talk to your customers – what are the most important ‘features’ to them – understand how they are making their decisions and appeal to those. Breadth is rarely the winner, particularly if you are just starting out. You need an angle.


  • Considering scaling never happens in a ‘vacuum’, system factors need to be taken into account. Scale the environment, pick the parts to minimise and those to maximise.
  • There is unlikely to be ‘one right way’, treat scaling as a ‘test and learn’ process, adjust as you go, listen to the feedback coming in, and act on it.
  • Scaling isn’t a switch – its a continuum and you must monitor the system constantly for opportunities to turn the dial-up and when to turn it down.
  • Not every capability you add will help you to scale, make sure it takes you closer to your goal and doesn’t add unnecessary complexity.
  • Understand the external factor dynamics and their effect on the product, use it to guide you where to focus in order for maximum impact.