Scale Friendly vs Innovation Friendly

Ochade Udome
Product Coalition
Published in
4 min readSep 28, 2022

--

I am so sorry but this article might make you rethink some organizational decisions you have made in the past.

If you haven’t made organizational decisions yet, you might just be in luck.

I always start with a definition before delving into details. Let’s go!

Scale friendly

Scale friendly is simply put — making a plan building a product, marketing it, and scaling up from there. I’m sure you’ve done this or you’re doing this or you plan on doing it. Either way, no pressure. I’ve done it as well.

The scale-friendly method is very common to us all. It has been used for decades even by some Fortune 500 technology companies. We use it in our everyday lives, but using it to build a technology product today — you have to think again. To use a scale friendly method, you have to start with a plan.

As part of the software development lifecycle (SDLC) model, you start with a plan which can include — budgeting, gathering the right talent, deciding on the right tools/frameworks to use, and other items to implement the plan, and then we are left with the outcome.

For some companies, the scale-friendly method ends with a focus group. With focus groups, the product is presented to users and they share feedback and suggest features that can make them enjoy the product more or give critiques on the product. The product is then brought back and modified to incorporate feedback and suggestions — which sometimes can cause delays in releasing to the market.

Now imagine if you are not successful in scaling this product. All the time and money spent on building this product is wasted.

Innovation friendly

The innovation-friendly method prioritizes understanding the concept of this product idea to the tiniest bit. It usually starts with scoping out clearly what we’re trying to achieve, mapping the product (solution) to the problem, and carrying out user research to better understand the need of the product before going on to build the product. Only if we confirm there is a need, do we proceed to build.

The innovation roadmap

In the typical innovation-friendly method. We try to understand user’s habit, their triggers, and what makes them click and tick ( watch out for an article with this article). A good tool we can use to study that is the Nir Eyal’s hook framework. We go to where the users are. the below terms are as explained by Alex Cowan.

Triggers can be internal or external.

example with a product I'm working on

Triggers refers to the feelings or events that initiate use.

Action:

Is there anything that can hinder the user when using the system?

Reward:

How is the user gratified by their action? Our example: sees a list of competent candidates and their details.

Investment:

How does the user accumulate a preference overtime? Our example: recruiters continually use the product to find qualified talents.

You may go on to do yours on a piece of paper with a product of yours or any other product at all.

Scale friendly vs innovation friendly

The scale friendly method assumes the product is something worth scaling while the innovation friendly checks the value of the product and if it is worth the risk. The scale friendly method is just another waterfall method, while the innovation friendly method fits well into an agile environment.

To learn more about this concept further, I found it helpful to review this presentation via FutureLearn by Alex Cowan: Scale Friendly vs. Innovation Friendly.

The downside to an innovation friendly approach is the fear of your team being idle for too long, but it is still better than building a complex product and trying to scale.

I’m now a fan of whatever drives innovation. Before now, I tried building a product with the scale-friendly method, and now that I’ve found out about what drives innovation. It’s time to take a U-turn. This will cause a lot of delays, but no worries — better to get it right now than later. I hope this article leads you to build more innovative products in the future.

Special thanks to Tremis Skeete, Executive Editor at Product Coalition for the valuable input which contributed to the editing of this article.

--

--

Formerly Documenting my way into Product management now Documenting my Product management journey. Aspiring Forbes Contributor. Email: ochadeudome@gmail.com