SaaS and Lean Startups, Baby Steps the Theory of Evolution and the importance of Tests

I agree this is a radical title for a 10 min read article. Do these concepts even make sense on the same book?

Here I'll expose a point of view which ties those topics together in the hope it will be useful to product managers that want to improve the quality of their SaaS products and the joy in making them come to be.

Before we start, lets contextualize:

• SaaS products are ever evolving. No one is really able to fully specify a SaaS product a priori. Google, for instance, took 5 years to get gmail out of beta state and they continue on the move;
• A great deal of the Lean Startup technique functions as an alternative way of product planning -- specially the product requirements planning;
• The path a successful product takes (in the Lean Startup methodology) should be split into "baby steps": each deliverable set of changes must provide improvements over the past versions -- or else you will waste resources.

This implies that a question must be continually answered: will this next delivery really improve the product?

The question has two perspectives and can be broken down:

1. Will this next set of changes in the product's specifications really improve the perceived quality / total cost of utilization ratio?
2. and: Will the result of the execution (the way our team constructed and tied together this next set of changes) also improve this ratio?

Let alone trying to find "the next set of optimal changes". This is an utopy. Once you picked any set of changes (optimal or not), you should be able to determine how they answer question 1 and here the science vs art discussion in software development starts again: on the science side, with a decent customer relationship and a spreadsheet you are able to create a backlog of requisite changes and relate them to the benefited audience perceptions; on the art side: what set of changes should you pick together for the next release in order to maximize the outcome of question 2?

The answer to question 1 is solved with numbers and formulas, but the answer to question 2 is usually done in "a feeling". Is there a better way? Here is where the evolution theory comes handy.

Lets recall that the Theory of Evolution demonstrates that improvements on the quality (of living beings, in this case) are done in a process executed by non-intelligent entities (in which the laws of physics, the environment, other beings and some randomness mutations all take part). Evolution also can only happen in small sets of changes which responds positively to the questions 1 and 2. As with good crafted software, the products (of evolution) are also tested and measured and bad outcomes are discarded. The analogy stops here. And we get to the main point of this article:

What are "baby steps" and how can I make the best use of them?

Baby steps are nothing more than the set of small changes needed to achieve a desired great value in the future. In the Theory of Evolution, this great value can be so great that, over the history, many was led to believe that the process cannot be guided by unintelligent entities and that must be a "coordinator" behind it -- because, if not, that desired great value never existed in the first place and the results could only be achieved by pure luck. The most used example in this subject is the evolution of the eye. The same applies for all other great valued features: skin, movement, brain, muscle, bones, wings, ... everything. The eye, in summary, followed these "baby steps" -- this may seem to off-topic, but follow me on the software requisites analogy I am trying to build. Imagine a primitive world consisting only of blind creatures:

• First, a set of cells sensible to light develops on the skin of a creature. Possibly a cell membrane protein able to send a stimulus to other cells developed randomly, by mutation. The creature now is able to tell if it is in the light or on a shadow; or if it is day or night. This first meaningless step is valuable: fungi seem to have stopped here. Will they sprout or wait until the spores are moved where there is not direct sunlight to dehydrate them?
• Some other life forms were able to come with another little change that brought them an additional advantage: suddenly these light sensitive cells happened to be on a slightly depressed surface. Again, that would possibly be mistaken as an aberration: all beings got a straight body, but this one had a depression on it. A horrible mutation, if someone was there to look, but which was able to give the creature a better sense on the direction of the light source. And that was enough for plants -- they don't need more to achieve optimal growth decisions.
• You got it. The next steps are improving the depression and improving the ability to detect the direction of the light source, covering the depression further and further in order to contain the sensitive cells in a hole, which helps to better focus the light, than a coverage to protect the sensitive tissue and guarantee a controlled fluid for the light to travel and after that, lenses to focus both on far and close objects.

Are you still with me?

Now you got inquired and your clients want a huge feature, such as the addition of vision. Life would be much easier if that happened, wouldn't it? Your solo work would be to split tasks, leaving all the intelligence of planning the product future to the customers. I never saw that happening with a good result. Clients usually say "I need it to dance". After careful conversations, analysis and talks to the team you determine that "seeing" is what is needed -- because your product already "walks" and the combination of the two will be flexible and optimal. Isn't it like that?

But, nonetheless, lets say that you determined that huge future feature will be "sight". How to split up the tasks? Many product managers will rely on the clients for that. Others will "trust their guts" because they have "a feeling" of the situation. Can't you use science? Evolutionary Science? Sure! But many times that seems art, I have to say.

First, while the customer awaits for that important feature to come to be, will "some little sensible cells" that will just tell you "move or stop" be of any value? If the answer is yes, you are on the right path. Let the team work on it in a way they understand and can come up with a test for -- a technical test. This will improve the results of question 2, stated at the beginning of the article.

I believe you got the idea of the process suggested here: working on small changes just because they are small isn't enough. It isn't even enough if you work on small changes that were driven only by the customer perception of value: they may lead to nowhere in the future -- a creature that, in the end, can't see, can't fly, can't move. The product manager must know where to go with the product on the long run. He or she must be talented to guide the evolution into that direction, guaranteeing that on each delivery a customer need will be addressed and the perception of the product will be improved. Some times selling or promoting a feature is needed. It is all about perception, in the end.

Another (less artistic) way to think about this is to combine the results of question 1 and question 2. If you only guide the evolution of the product towards answering good the question 1, you might end up with an unintegrated product (like a Frankenstein) which will fall on itself on the long run -- have you ever seen a product which developers cannot develop anymore? Most are caused by wired requisites. If you consider how the next set of changes will be executed and also integrated on the existing features, you may be able to filter out some requests. For that considerations to be successful, it is imperative that product managers participate on automated testing planning. If you want to build something that you don't know how to test, that think will probably not be able to be built. What usually happens is that the technical team does the work of the product manager in this regard. With all this argumentation, I am suggesting that the responsability of designing tests should be taken by product managers.

Coming back to our analogy, designing a test is what an intelligent designer would do if he or she didn't want to interfere in the evolution process -- would eyes evolve if they were not stressed out and bad eyes were revealed? To build great software you, as a product manager, don't need to code, but you do need to guide coding -- even in the low level. This is done with test plans.

Here at Mutua Tech we successfully use this approach in the constant process of planning and implementing our SaaS products.

Please, leve your comments bellow.

Luiz Silveira.