"Minimum Viable Product" jive
My college homie Dave is working on the “Minimum Viable Product” (MVP) version of his Baqbeat product. I’m always interested in what old friends are doing, so I asked him about it.
Baqbeat is a little hard to describe. Dave filled me in:
Baqbeat generates timelines of configuration changes to all the servers in
your development and operations environments – version control, build
servers, app servers, databases, and others. It automatically infers
related events on different timelines. So for example, you can see problems
in your production environment and immediately trace it to the code change
that broke it.
Now Dave is going with the MVP model because, in his words, “MVP. First sale. Investors. In that order.” Wisely, he figured that there’s no special prize for waiting for Version 1.0 to be perfect. Get enough done so the product is usable and delivers some benefit to the customer and provides feedback so he knows what to work on next.
I’ve read a little bit about the MVP concept and talked to some local people who are hooked into the venture capital community and it turns out that we see things differently. To some venture people, you know where the “minimum viable” point is? When the product is complete vaporware. They actually promote a product that doesn’t remotely exist and see how many people try to buy it!
The cool thing about this is that you can cut your losses really fast when the product doesn’t make market sense. You invest virtually nothing but a few advertising dollars. Maybe the cost of a domain name?
That sounds super-sketchy to people like me and Dave who actually make things for a living. (True, the things we make are fairly abstract, made out of ones and zeroes, but at least they’re not just vague ideas.) The least you can do when talking about your awesome software product is to have at least some of the code written, right?
But the “vapor MVP” model also doesn’t work for Baqbeat for another more fundamental reason: It’s not something you can sell with a name and a catchy slogan. Nobody’s going to purchase this thing if they can’t see it and mess around with it a little. And try it in their enterprise.
I was looking for a way to describe this distinction when I came across “Three Reasons Not To Build A Minimum Viable Product” over on Pando Daily. Writers Cooper and Vlaskovits put it really well in reason #1: “You are building a sustaining innovation product.” Baqbeat isn’t sustaining innovation; it’s disruptive innovation. People aren’t going to know they need Baqbeat until they see the sorta-kinda-Baqbeat-pre-release and get it. It’s a new market and the customer literally doesn’t know what they need.
So if Dave went with the “venture MVP” concept, and just told people what’s this product would look like, they’d be saying no to something they couldn’t remotely understand. No, he has to make an actual, non-vapor MVP. That’s the only way his potential customers will know what they’re missing.
Put another way, I learned years ago that marketing is part of the actual product. Here, what Dave is experiencing, is that the actual product is part of the marketing. They don’t go hand in hand: they are the same thing.
So you know what? I’m really interested in seeing this thing when it’s functional enough to play with. In the meantime, rock on, Dave.
The product is the marketing - on MVP and disruptive innovation - Baqbeat! | Baqbeat!
April 27, 2013 @ 12:44 am
[…] “Minimum Viable Product” jive, my old friend Mark Schumann brought up Baqbeat on his Critical Results blog. He wrote of how the […]
Baqbeat in Tech.MN
June 15, 2013 @ 11:06 am
[…] Beta Bytes series. It’s the second mention of Baqbeat in the outside world. The first goes to Mark Schumann’s Critical Results blog, where he talked about the idea of Minimum Viable Product and how it relates to disruptive […]
Change observation, not change control | Critical Results
September 3, 2014 @ 10:31 am
[…] while ago I posted about Baqbeat, an enterprise systems management tool being developed by my college homie Dave. A […]