Lessons learned: Creating New Products takes Heart and Maths

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:

1. 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.
2. 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.
3. Only a real change can be called an iteration. Bug fixes don't count.
4. Build, distribute to team members, test, get feedback as often as possible.
5. 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.