Minimal Viable Team to create a Minimally Viable Product

Despite being a bit of a mouthful to say “Minimal Viable Product” and the even more difficult to say “Minimally Marketable Feature” (also known as a “Quantum of Value” or “Business Value Increment”) are very useful concepts. What makes gives them killer power is that they speak to a secret belief held by many people (not just managers) that teams gold-plate development and create products with more than is needed.

The trouble is, while we all agree the we should develop Minimally Marketable Features (MMF from here on) and delivery Minimal Viable Products (MVP) it is actually quite hard to do this. Nobody seems to want to sacrifice their favourite feature or the styling they have set their hearts on.

In Business Patterns I have a side box entitled “Strategy means saying No” in it I say “One of my personal rules of thumb is that strategy is about saying “No”. Strategy is not so much in what you decide to do – saying “Yes” is easy – but in the hard decisions about what you choose not to do.” The same applies to product development: saying Yes to a feature is easy, saying No is hard, but unless you say No a lot more than Yes you won’t have a MVP.

(After completing Business Patterns I discovered that both Michael Porter and Tony Blair have made the same argument, that No is more important than Yes.)

I have come to believe that one of the reasons teams find it difficult to create MVPs made up of MMFs is that the teams are just too big. I would like to suggest that if you want to create a MVP then you need a Minimally Viable Team. i.e. a team which is only just big enough to create the product.

Indeed, I will go further and suggest that your Minimally Viable Team (MVT) should be slightly smaller than you think you need.

Basically my logic is: if you have more people you will create more product. If you constrain the amount of effort that can go into a product then you will constrain the thing that is produced.

Way back I worked on Railtrack privatisation in the UK. When I joined the team is was 120 people (although only about 12 actual coders). The project was massive. Out of that came by belief that inside every large project is a small one struggling to get out. I sometimes call this Kelly’s First Law of project complexity: Project scope will always increase in proportion to resources.

A few years later I found myself working on a data feed project at Reuters. In retrospect the team was overstaffed. We didn’t need COM based system with interchangeable components. We made work for idle hands.

I know one team I’ve been visiting for over a year now, MMF and MVP frequently come up in discussion but I see the product backlog getting larger and larger and larger. The team is quite large by today’s standard - over 30 depending on how you count it. And ever since people started talking of enlarging the team the backlog has grown faster.

So much for the observations, lets try logic.

If you think about this the need for a MVT to create a MVP is a direct result of Conway’s Law: organisations will create systems that are copies of the organisation. (Seven years ago Lise Hvatum and myself investigated Conway’s Law in a conference focus group, the result was “What do we think of Conway’s Law now?”).

This can also be stated as the Homomorphic force: the structure-preserving relationship between two sets of things.

If you create a team which is too big it will produce a product which is too big. Once you have created a team which is too big it will find work for itself to do and it will be very very difficult to reduce the team size.

So start with a small team: actively try to break Conway’s Law, break the homomorphic force.

Staff the team with a fewer people than you think you will need, staff it with a range of skills but avoid making architecture assumptions in your staffing (if you include a DBA and you will have a database in the system.) As and when the team demands to grown then grow the team grow it.

Use Conway’s Law to your advantage: create a Minimally Viable Team to create a Minimally Viable Product.

How small is a MVT? I would say two people.

Really you need three people for it to be a team but in the belief that you should start smaller than you think I say two. One of these people should be focused on the business side of things - requirements, need, problem domain call it what you will; the other on the technology or solution domain. Let them work the problem for a while and see what happens.