top of page
  • Writer's pictureNathan Kirchner

S-Curve, stage gates, product delivery... numbers, who cares!

Famous last words... but... this will be a quick one! But, one worth getting out there. Well, it would have been good for me anyway! So... if I am going to attempt to deliver my idea I should I be taking direction of travel tips from the well known S-Curve ( Should I navigate via the product deliver stage gates ( Other? Like many things in my world, there are several intertwined, cross-dependant, overlapping ideas, realities, perspectives & pathways all noodled together in what can only be described as a soup of confusion.

But to draw clarity from confusion - It is actually pretty interesting because these two seemingly very different lens actually share a common solid backbone. I will highlight that in a tick but first let me give the a brief intro for the underlying concepts within the two (WARNING: Strap in for a bit of generalisation, blurriness, & poetic license).

S-Curve - This is a quiet well known, detailed, discussed, challenged & refined encapsulation of the base concept that we generally start with relatively low numbers of units going out the door, then there is a explosion of unit movement, which then tampers off after sometime. See & google "S-Curve" for a LOT more words on this, I've done it zero justice, but just want to get the very basic concept into the story.

Stage Gates for Product Delivery - Here I am referring to the process I've honed over <too long> to improve my ability deliver products/services. The basic concept here is to stage the fidelity or your idea encapsulations (& thus effort that has gone into it) with the type of question you are looking to answer. E.g. The bookends of these stage gates may look at "Is this a good idea?" Vs "How do I make 1,000,000 of these a week?"; something made out of paper may be useful fo the first question, engineers should be involved en masse when we get to the other end though! A few more words on the 'Why, What, How & When?' of this are here:

These paradigms are kind of looking in different directions but there is a common solid backbone that is heavily grounded in <the hard to negotiate with> reality. That common solid backbone yields the relief of recognising the Catch 22 of we only have enough business-tech-product clarity ( to small batch prototype - we are young in the delivery / market penetration process & we can only move a small number of units. Sure the time frame can be squeezed & the unit movement volumes grown with more resources & less business-tech-product risk but the basic shape & the realities of having to move through the delivery gates remains.

<the ubiquitous 'honest question'> 'Cool story, but who cares?!?'... Well, actually, side note, is that a Catch 22? It feels more like a reality to synchronise on. Nevertheless, it is a reality that imposes a perhaps more achievable set of expectations on what we need to deliver. Expectations towards 'we need to maximise our ability to deliver & ability to satisfy demand simultaneously'.

<the insight> We benefit from synchronising our progress through these two well known scaffolds. It is less important if one starts with a business, tech or product focus as all need to be considered & more important we recognise that this is an iterative process. What is important is we realise that there is time & effort required to move through the tech maturity, product-market fit, business fit processes. There is little benefit for one to be well through the process when the others are far less so. For instance, what if the engineering is solid, the tech is great & we've made a million units already to only then find out no one wants it - the classic 'solution without a problem'. The question we ask is 'how much should we do to learn we is critical to progress from here to the next step?' and not 'how much can we do?'

5 views0 comments

Recent Posts

See All
bottom of page