Scope creep can be expensive, delay more important development and dilute the core value of the product. What is genuine product development required to get the product off the ground and what is scope creep? And what if there are not clear boundaries for the first version of a product, meaning the scope is not really set in the first place.

This is the second blog post in a series of reflections based on my time as a startup CTO for a SaaS-company in the wine and food business. You can read the first post here.

Making Headway

We were building a great team of developers, testers, architects and devops that were definitely up for the task, most of what was thrown their way they delivered.

We have set up a test strategy that bit by bit made our deployed features higher quality and less likely to break something. We still did a lot of manual testing but also started to build test automation.

Our development process was incrementally improved, of course there where still issues but the big backlog from the first full-team retrospectives were gone.

We’ve changed a lot of the things in the system that we didn’t like and that was negatively affecting the product. Without going overboard with the refactoring of course.

So things actually looked rather good. I was happy with the way things were going, the people in the team, our combined skills and our friendly way of working. I had great trust in my team.

Product Scope

There was a bit of technical debt from the development of the product but the general idea was that the product was feature complete already before I started the job. So in theory the timeline shouldn’t have drifted more than a couple of months to get a good enough product out the door.

Reality was something different. We were not getting customers in the system any time soon.

I get it, in a startup it is impossible to foresee everything and there’s a lot of trial and error. Trial and error, that translates into time and money being spent. When the product is not as thoroughly scoped as needed and also casting a wide net in terms of target audiences there’s a potential for a great drift in time-line and resources spent.

The idea of MVP in our case translated to Maximum Viable Product which I believe is rather common, but also an expensive error to make.

As stated in the previous post our user forecasts and therefore requirements on the product was rather big. And without any data to back up believes about user behaviour, performance peaks etc, we we’re only guessing what was required to meet these requirements.

The lesson is as painfully simple as it is well known. Start with small scale and make sure the customers really want the product. Do not try to take over the world day 1. Even if it is tempting.

Small increments of improvements will also get you to the goal, with less strain on the team and finances. In my view we wanted to, and tried to, solve too many things in the first try. It made the product complex and difficult to boil the features down to a simple and striking sales pitch. Which we really needed.

The Product itself actually was incrementally developed, with more and more fixes, features and improvements deployed to production every month. But we where not able to translate the product improvements to sales.