Never start with a scalable product. Too often people want to create a fully polished product before they even validated that it provides enough value for people to make them pay for it.

NEVER START WITH A SCALABLE PRODUCT

In this article, I’ll show you the three product phases that your startup/product will go through if you’re focussing on value first.

I explained the concept of the #valuefirst mindset previously in this article.

One of the most important tasks as a maker or an entrepreneur is to keep your focus on the primary goal and to learn how to divide the necessary from the nice-to-haves.

Throughout this post, I’ll be using the terms “product”, “service” and “solution” interchangeably. They all refer to the thing you, as a (potential) maker think will be a viable solution.

Keep Your Focus

It’s hard to stick to the absolute necessities. I’m not just talking product features here. For example:

  • User communication & support
  • Backend automation processes
  • Scalable architecture
  • A database that supports high volumes
  • Automated admin processes
  • User interface design
  • Functionality that’s handy but used only 10% of the time
  • And the list goes on…

All these items take quite the effort and time to get right. And — although they are really important — they all have a time and place for when they must be taken care of.

When you’re planning on creating a product or service out of thin air, it feels logical to take your mind down that theoretical path and find out what challenges might lay ahead a couple of miles from now.

It’s only logical to try and build things that can prevent those challenges or at least support the situations they might show themselves.

Most people have been conditioned their whole life to scan for possible failures and start working around that. Parents, your study, society.

But the bare truth is that taking all that into account while you’re still at the start of you (and your product’s) journey, will not get you to that finish line of shipping a viable product any faster.

Nor will it make you do it with less effort, time, and money.

Focussing on the value that your product will bring helps to do what is needed, but nothing more. And that’s what this first of three product phases is about.

Just like evolution, your product will need to go trough the three product phases to make sure its main focus is viability

The Three Product Phases

When you’re focussing on the value that your product creates, you are necessitated to extract any excessive product feature (product fat), keep your processes lean and to a minimum, and invest minimal effort and time until you’re sure that your assumptions have proved themselves and it pays off to go to the next level.

I don’t need to use many words to indicate that using an agile workflow to create your product during incomprehensible and scoped iterations is the way to go. 
The Lean Startup by Eric Ries has proved to be a clear and effective framework for product creation.

As you start your value focussed product creation journey, and iterate your way towards a viable product, we can define three phases that the iterations will go through.

Getting to know them will help you to more deliberate focus your next sprint to set you off to the next phase when — and only when — your product is ready for it.

Product Phase 1: Proving Value Generation

Phase 1: creating the simplest solution that creates value and brings in revenue. Like cutting out a simple road through the jungle.

Let’s take the concept of creating an MVP — which is an abbreviation that stands for Minimum Viable Product — into consideration.

In the first phase of your product, you’ll want to focus on the Minimum part. Using the least amount of effort to see if people are going to even use your product, you’ll be showing them just enough and creating just enough functionality to provide them with added value.

If your product would be making a road through dense jungle to help them get to the other side faster, you would aim to find out if there is a need for such passage. And if that need (this is the value it provides, ie: saving time or being cheaper than using the river)was big enough for them to pay for the toll (your revenue).

People might have been talking about it at the bar, mumbling that a road through that thick jungle would help them a lot.

Would you take this as a sign to where you need to build your road?

That’s fully understandable, but from a business perspective, people can talk a lot. As soon as they leave money on the table for your idea, you’re talking about conceivable proof that you’re making the right decisions.

You won’t know if they’ll walk up to it and use it. You need to find out which spot is convenient and close enough for them. And you’ll need to be checking out what part of the jungle is easier to flatten and clear of trees.

You can use a lot of tools like polls, or setup signs at multiple locations that have been used as simple paths by local folks to see if more people will use them.

What you’re NOT going to do, is take into consideration all the things that might be important 10 years from now.

With almost no money in your pocket and no time to waste, you’ll focus on creating value in the short run and making sure that you’re providing enough value so you can ask money for it.

Asking toll for your new road and receiving it will be the confirmation that your road will be used and provides enough value.

To summarize the first of three product phases, during the first phase our focus points for creating a product are:

  • finding out if there is a value
  • focus on making only the minimal demonstrable version that shows users what that value is
  • find out if people think the value is great enough to pay for it (be aware: paying for it is the validation, not them saying they’ll pay for it)

Things that are no-go’s during the first phase:

  • doing things that scale
  • investing time and money in building facilities that are only needed 10% of the time
  • thinking about scenarios that are unlikely to happen (short term)
  • setting up tools and processes that you might need, and have not proven a need for

Exempli Gratia

For the jungle road example, the goals for phase one might look as follows:

  • finding out where a road might be most useful to the most people
  • cutting out the basic version of a pathway through the jungle
  • not considering large trucks, trains, etc. just plain folks and smaller vehicles
  • setup a toll post and find out if people will pay you to walk your path

If you’re working on a SaaS solution, in the first phase your goals might look as follows:

  • you’ve only styled a front-end
  • using some Airtable form, Zapier API integrations and a free online hosted database with email service integration, you’ve created the MVP
  • people need to pay upfront to be able to use it
  • when someone forgets their password or needs to change their email they will need to contact support via an online form or email
  • you only support the latest Chrome, Firefox and Safari browsers
  • enterprises can be hooked up, but you’ll need to run some queries and help them out manually to them setup.

Product Phase 2: Expanding Value

Phase 2: improving your product to help more people with the least amount of effort. Like widening your jungle path and adding primary features like signs and a gas station to keep people going safer and further with your product.

Many makers tend to hush trough — or worse, even skip — Phase I. They want increased revenue and tend to take risks by not aligning the value creation with a focus on the right users.

It makes them feel insecure, and unsafe to spend too much time with a product that doesn’t feel “finished” and perhaps even flimsy from a technical standpoint. But taking Phase I seriously and using it to its full potential helps to lay a greater foundation on which you can build the next product phases.

Once you’ve set down the Minimum Viable version of your Product (the MVP), you can use the revenue or stable growth to improve your product.

Instead of checking your core assumptions about the product, in this second phase, you’ll be focussing on refining the product and making sure that more people can make use of its value with the least investment on your end.

Now, I (by any means!) don’t want you to build shaky thinks or create shady solutions that promise to do more than they actually can provide for.

But you do encourage you to keep the value that your product creates as the main focus point.

With everything that you are opting to change, supplement, or integrate, you will need to see if it helps your product to gain the most value with the least amount of effort.

One way of attaining that goal is by using the Pareto principle (also known as the 80/20 rule): find out if what you’re planning to do will reach 80% of your value increasing goals using 20% of the effort.

Using your existing (paying) customer base to resonate your intentions towards will provide to be a great way to find out if it helps.

Don’t fall into the pitfall of building about every request that customers throw at you more than once.

Write recurring requests down, and prioritize them. Talk to customers to find out what they’re trying to overcome or solve and see if there is a better solution and/or a solution that is easier to fulfill.

The same advice counts for improvements that you’ve initiated:

Talk. To. Your. Users.

When looking at this phase purely from a technical standpoint, this is the phase where you’ll be wanting to add things that take more people over the line to use (and pay for) your product.

Things like including enterprise features and support for your SMB-focussed product (or vice versa) often tend to be good investments during this phase.

Also, things that improve the user experience for the highest usage flows and parts of your product improved support integration, automated processes for actions that weren’t scalable (read: manually done by you) in the first phase, are great ways to gain you more time.

Precious time that you can invest in other activities to improve your product.

Exempli Gratia

When looking at the jungle road example, this phase might include:

  • increasing signs and safety measures so people can drive over your jungle path
  • add multiple lanes to increase traffic throughput
  • add a gas station and restaurant to keep them on your road longer and replenished

For a SaaS solution, phase two might deal with things like:

  • Easier user flows
  • Drafts of work in progress and on-the-fly saving
  • Authorization integrations with the most popular auth services
  • Integrations with enterprise packages for i/o with your product
  • in-app support chat and easy-to-use FAQ documentation

This phase is the part where a product — at least one that proved viable and sustainable — tends to be at for a way longer period than the first phase.

Phase II is the phase where increasing value, product refinement, increasing usage & the total number of users and improving the user experience take up most of the work.

Start Phase II too soon, and you’ll be investing time and effort in a product that might slide off the user’s interest because the value creation is crumbling or might appear off later in the game.

Start Phase II too late and your product might lose interest from users as they don’t see it grow and improve fast enough (and competitors might have been surpassing your solution).

Product Phase 3: Strength And Sustainability

Too often, makers want to create something that’s hard to take down, does everything that they can think of that users might want to have, and want it to have the cool appeal with a low effort autopilot mode from both development- and support perspective.

But this scenario just as unlikely to ever become reality as finding the Holy Grail.

Too often, coders, architects, and what not want to try and build something that is sustainable, scalable, and error resistant from the moment they are thinking of the project setup.

And that just is a pity.

Enterprise architectures. Extensive design patterns. Service-oriented architectures. All of these are brainchildren that were created to solve one large scale risk or another.

To harden a solution’s resistance against the tides that might be lying ahead. They take seniority, time, and a lot of investment.

But these are often investments that are all being made “under the hood”.

For a single user, they won’t be adding to their value.

“But if we don’t implement these, our system will slow down or might be crashing on us”.

Although this isn’t desirable from a commercial standpoint: capping the user count might fix that way easier.

But when you come to think of it: if you’re focussing on improving the value that your product gains for its users will make it easier for you to increase pricing. Even if it means letting go of a percentage of users so you can get more revenue from the remaining users, you’ll still be growing. Just growing value-wise, and not solely on the number of users.

By the time you’ve reached Phase 3, you’ll have the luxury that the product is sustainable enough to be thinking about its perception. If you can increase its likeability and make it more appealing to more people with a low effort, this is the time to do so.
This could mean that you’’ll be working on the product positioning, to let more people learn about your product and see its value for them 
(check out April Dunfor’s Obviously Awesome: How to Nail Product Positioning so Customers Get It, Buy It, Love It).

But it also could mean that you invest to improve the user experience, to enable more people to understand and use your product to its fullest potential.

Phase 3 is the phase where parts of the foundations of a solution are going to be rebuild from the ground up. This can be because of a lot of reasons, ie:

  • it will make it easier to scale your solution
  • doing so helps you to make your solution available to more types of customers (ones that you weren’t targetting initially)
  • new technology has become available that will let you do more with less code
  • doing so improves the user experience or increase the speed of your product (thus increases the value of the product as-is)
  • and the list goes on…

Don’t mistake my reference towards rebuilding with “implementing enterprise patterns” for your product.

As David Heinemeier Hansson (the creator of Ruby On Rails, known as DHH on social media) so correctly states in his article The Majestic Monolith, applying all these patterns because it worked for big companies that are servicing tens of thousands of users out there, won’t fly.

A quote from DHH’s article states:

“The patterns that make sense for organizations orders of magnitude larger than yours, are often the exact opposite ones that’ll make sense for you. It’s the essence of cargo culting. If I dance like these behemoths, surely I too will grow into one. I’m sorry, but that’s just not how the tango goes.”

When you’re a solo maker or working with a small team to create and improve your product, you won’t be helping yourself OR your users to start and implement 7 layers of software over 5 projects within your solution.

Neither will be adding all kinds of flashy and trendy patterns to help your users to get more value from your product.

Increasing the usage of abstract patterns that also tend to increase the complexity of a technical solution, often proves to be an inward investment: fun for people who are aiming to learn how to implement such patterns and making you more secure of “holding the structure when the user count increases a tenfold or more.

Keep your nose on the focus point here like I pointed out for the previous two phases and keep continuing to ask yourself:

What brings actual value to the user?

Please mind that Phase 3 will only be applicable when you’ve proven to have created a sustainable product during a longer period:

  • your solution works
  • the product proves to keep providing value for a multitude of people and will do so in the foreseeable future
  • your revenue is high enough to keep persisting the product and investing in it

When you can mark all three bullets, you know you’re riding on a good wave and your product is worth investing in during phase III.

If one or more bullets are shaky — perhaps competitors have submerged, or your product is losing its relevance because of other external factors — you’ll need to sit out phase II for a longer period and find out how to steer your product towards an increased value-generating focus point.

Exempli Gratia

For the jungle road example, Phase 3 might include:

  • Integrating other means of transportation into your road
  • Make the road ecologically and environmentally sustainable by digging it underneath a part of the jungle
  • Add value by restoring the jungle part you’ve removed
  • advanced railing reduces the number of fatal accidents (lowering the risk of using your road)
  • modern high-speed roads let modern vehicles proceed effortlessly

For a SaaS product, phase III can prove its value by:

  • Minimizing effort on your (team’s) end by automating 90% of support processes
  • Self-help features let users do most of the necessities by themselves
  • Splitting your functionality from the interface using things like an API helps more parties and services to benefit from the value your product provides
  • Smart refactoring improves the scalability of your solution

If you’ve made it to a phase III product, and you can find ways to invest in increased value creation through refactoring and/or improving the solution with the least amount of effort, you’re up for a great ride.

By this time, your solution might even prove to be reaching its maximum percentage of self-sustainability.

To conclude

There is no one road for any business and the same counts for the products and services that they thrive on.

But the three phases that I’ve detailed in this article are real nonetheless. If you understand what the focus of each phase is and how it can help your product to evolve, you can use that to your advantage.

At the very least, I hope that the oversight of the three product phases that a product will go through when built from the ground up might help to assure you that it’s okay to take your time to find out if you’re creating something that’s wanted.

And that focusing solely on value creation without building an MVP that’s suited up like a tank to survive every scenario is the cleanest and best way to keep agile and flexible when you’re starting on a product.

It’s time to focus on value first, and use both that focus and lean product creation as Ariadne’s thread that leads us to a viable product.

So we will create a product that’s packed lightly and that will take us the minimum amount of resources, or as close as we might ever come to that.

Code Hard, Ship Harder ?

This article is also published on Medium


Also published on Medium.

Edwin Klesman

from 1981 | husband | father of 3 | former (cross-platform) mobile developer | former Tech Lead @ startup | Team Lead (www.edu-deta.com) | Owner EEKAY ONLINE (www.eekayonline.com) #valuefirst #productdevelopment #consultancy | hooked on entrepreneurship, startups, product development, apps, SaaS

View all posts

Add comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Bringing you mindshaping content that helps you to build viable products & documenting my journey as I use the approach on this website for myself to build viable products.

About me

Edwin Klesman

from 1981 | husband | father of 3 | former (cross-platform) mobile developer | former Tech Lead @ startup | Team Lead (www.edu-deta.com) | Owner EEKAY ONLINE (www.eekayonline.com) #valuefirst #productdevelopment #consultancy | hooked on entrepreneurship, startups, product development, apps, SaaS

“Educate yourself while travelling” – Audible

Advertisement

Advertisement

Subscribe now

Sign up and get the latest from Shipharder.com in your email