This lessons learned series is part of our live SaaS resource list we're
building while launching a new product.
What one sentence was most important to our product creation and why?
"If you start out with $100 at the beginning of the year and you were able to
increase what you have by 1% every single day, at the end of the year, you
would have $3,778.34 = $100 * (1 + 1%) ^ 365. That is 37.78x what you had at
the beginning of the year. Get that 1% every single day!”
We find that new product ideas are always exciting.
However, that excitement is about the general direction of the product and
what it's capable and the details are where the work is.
The details of the product will be worked out through an iteration process
where each week we push out a new version of the product and test it, figure
out what's missing and rebuild it. We believe that 20 or 30 of these
iterations will improve the product well beyond our initial vision and help
expand that vision and refine it.
The quote above about 1% improvements and their compounding power feels like
exactly the right thing to keep in our minds when developing anything.
What dumb assumptions did we make about creating products at the very
start of our journey?
We had some experience in building products before Upscope so we were not
total novices but...
We only "half" knew things (which is quite standard in the early days of most
startups but it has a cost in time and revenue).
We knew that building a core quality product was important but we didn't fully
appreciate how it helps cut down support, sales and other problems later on.
We knew that a great design could make a big difference but we felt we had a
good enough design and we stuck with that for too long.
We knew that building too many 'not quite priority' features would create
technical debt but we still created a few too many and had to support them
afterwards. It's amazing how distracting 30 mins a day spent explaining that
one extra confusing feature can be in terms of additional time and energy
lost.
You can still grow a company if you "half" do some things but have you ever
seen how much sales go up with a great new design? It can be a massive lift.
More than spending months on dozens of new blog posts.
Have you seen how little friction there is in a product with a few core
features that work and are simple to use? You'll hear people tell you about it
during customer calls "we bought it because it worked and it was simple to set
up and use".
What's one the most worthwhile things we did after this?
The 1% rule listed at the top was used as an underlying philosophy for
reaching our initial internal build of our "Flows" product.
The most worthwhile thing done was to allow the excitement of building the
product but to make sure it was channelled into iterations.
The principles we kept in mind for the initial internal build were as follows:
-
Stick to a single core great product experience which we believe is needed
based on our understanding of the current problem and the flaws in the other
products servicing part or all of that problem. -
We assumed it would take 10 or 20 product iterations to achieve an initial
internal minimal viable product that met this high standard. In other words,
the first version was just step 1 of 20. -
Only a real change can be called an iteration. Bug fixes don't count.
-
Build, distribute to team members, test, get feedback as often as possible.
-
Immediately drop any features we feel are not absolutely critical to
achieving that single core great product experience. This is the hardest and
most essential part.
By around the 9th iteration, which took nearly 2 months, we had dropped more
than half of the features developed and that's effectively half the
development time. It's a brutal process but the speed at which average or not
quite essential features is dropped is essential to making it work.
What would we advise someone to do if they were building a product from
scratch?
You are either your own customer or you are building a product for customers
you can test the product with.
If it's for yourself then great, keep in mind exactly what you want to build
and don't keep half a mind on its external use.
Note, if it really is for you and you're fixing your own problem then you've
probably looked for other existing solutions to that problem and were not
satisfied with them, that's why you're building it for yourself.
That's how you normally fix problems, you look for existing solutions first.
If you can't find one or they're not up to scratch or they're difficult to
find and use then that gives you a clue about the state of the market.
If we had a magic wand how would we use it to improve our product
development now?
We'd have in-house designers who instantly understood storytelling and could
get to work on the design / story telling side of the product once we reached
that 9th iteration and had a good enough idea of what it was going to be when
we initially launched it.
The design, in this particular case, is an important component in ticking the
3rd box within "valuable, simple, fun". Right now the Flows product we're
working on is valuable and simple and making it fun would help increase its
distribution power by 10X, 20X, 100X? Hard to say but it's essential.
