Minimum Viable Product

Today's columnist is Emma Jane Hogbin (who, BTW, will be speaking at the Women in Open Source conference in a few hours). She writes:

A few weeks ago Eric Ries, author of Startup Lessons Learned, taught me my new favourite term: Minimum Viable Product (MVP). I learned the term during a session at an unconference. I was pretty sure I wanted to learn about micro-businesses, not startups, but Eric's session was as close as the schedule came to combining "small" and "business." The session was fantastic. If you're like me, you have a bit of a morbid streak that loves to commiserate with other businesses about your failures.

The session was full of delicious new ways to fail. My favourite example was tied to the explanation of a MVP. After weeks of working on features, a project was made available for download. No one downloaded it. The MVP in this case was actually a download link. It would have told the developers no one was actually interested in downloading the product they were creating. The link could have been empty and it would have taught them the same lesson.

Let's take a look at the definition of an MVP: "The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort".

There are a few key words and concepts in here that deserve special attention. "Minimum" and "maximum" are of course completely subjective. Your team will need to decide what balance needs to exist between these two terms. The second part of this idea is that you are looking for validated information about your customers. You don't need a lot of people to tell you things about your product, but you need to have enough to tell you whether your assumptions about your customers were right or wrong.

MVP, is similar to the well-known open source expression, "release early, release often." It goes a little farther though--it's not just about getting your code out; it's about getting your code out with the intention of learning something about your customers. In other words: it's not about your code; it's about your users. Just this week someone told me they pushed code they knew was broken to motivate another developer to complete a task they'd promised to work on. Ouch! Of course I knew they weren't actually pushing broken code out to the customer, just out to another developer. Their MVP was broken code. They knew broken code would be more successful at getting a feature implemented over having no code at all. Don't make this mistake with code you push to your end users. It will teach you only that broken code makes users angry, discouraged and it may even make them switch to another product.

Your product has to work for you to gain information about your customers. You must fully complete a task before starting the next. In my experience, 100% of a useful feature is better than 80% of 5 potentially useful features. Mobile text messaging and microblogging, when done right, is the simple exchange of 140 or so characters. There are all sorts of extra things that you can add to this but, at a minimum, the message needs to get from one person to another. If you think up a new feature to add to the first, make sure it too works before you ask the public what they think of it.

MVP doesn't need to be limited to code. Examples that may be relevant to your project include:

A/B split testing on marketing pages: what is the minimum feature list that will get people to sign up for notifications about your project?

AdWords: what feature description makes people click through an ad to get to your project's website?

Documentation: Do people really want to read an entire User Manual? What's the minimum documentation you can produce which does not result in support requests?

Take a look at the project you are working on right now and find your minimum viable product. Finish up that one little thing you're working on. Push your product out and learn the lessons your customers have to teach now. Stop fussing and start getting real feedback on what is going to make your project succeed.

You can read more about the concept of the Minimum Viable Product on Eric's Web site.

To "Open Source" or Not to "Open Source"

Today's column is by Julian Egelstaff of Freeform Solutions. Julian writes:

"Let me assure you that whatever problems the Mozilla project is having are not because open source doesn't work. Open source does work, but it is most definitely not a panacea. If there's a cautionary tale here, it is that you can't take a dying project, sprinkle it with the magic pixie dust of 'open source', and have everything magically work out. Software is hard. The issues aren't that simple." Jamie Zawinski, co-founder of the Mozilla project, at the time of his resignation in 1999

An odd question landed in my inbox recently. A development team was looking for advice about open source licenses. Specifically, they wanted to find a license that would:

• require the consent of the original developers before distributing the code, except among a small group of related organizations


• require people to notify the original developers if they use the code and if they make any changes to the code


• disallow the selling of software based on the code

Doesn't sound very open does it? That was my basic response...this team doesn't want to do open source as far as I can tell. But the idea of open source is out there, sharing code is a hot topic, and these guys did want to share code, just not very widely and only under certain circumstances.

I don't think they're alone. A lot of people feel very possessive of their code. A lot of organizations feel very protective of their investment in intellectual property. For some, sharing of any kind is out of the question. For others, it's an interesting idea, but they don't quite "get it" and they're not sure how it might apply to them.

My advice would be to follow the value. Where is it coming from? If you can answer that question, you'll know if open source is for you.

First of all, remember what open source is...at the end of the day, it's just a way of developing software. Like Jamie Zawinski said when he left the Mozilla project, open source is not magic. But it can have a powerful effect, when its practitioners come together and persevere. Mozilla may have had failures 11 years ago, but these days it's home to one of the most successful projects in the world, Firefox.

Open source is a way of developing software, that tries to leverage contributions from the entire community of users. In practice, only a small number of users contribute to the actual programming, but any user at all can contribute to bug reporting and testing, documentation, and even planning features for future releases.

To guarantee that collaboration, open source licenses enforce certain obligations on the users of the software, most notably that they must provide the source code every time they distribute the software to someone else. That way, no one is left "out of the loop", so to speak. Everyone is on an even playing field when it comes to the use and development of the software. At least theoretically.

The fact is, just having the source code is never enough. Even armed with the source code, no one is going to out-mozilla the Mozilla Foundation. Lesser projects may get forked from time to time, but who in their right mind could ever fork Linux?

Open source projects exert a powerful control over their own direction and destiny through all kinds of other means, besides the licensing agreement. The right to the source code may be the under pinning of open source, but just like freedom of the press in a democracy, it's the actions and ideas of the people who use that right which truly guarantee the freedoms that the right is there to protect. The community is as important to open source projects as the code is.

The right to the source code, and the will to pick it up and use it: those are the two mechanisms that drive open source forward. So what does that have to do with value? Well, if you're in a classic software development business, along the lines of Microsoft, then you're betting that the value in your business comes directly from your ability to develop software that is better than anyone else's, or at least more widely desired, and to essentially limit access to it and charge for every copy. Creating value in that kind of a situation means you've got to maintain a big marketing and sales team, and all kinds of things that don't have much to do with the act of software development, just to protect (or create?) the value that is ostensibly derived from your software.

The problem with that kind of value proposition, is that most people assume that's the value proposition all software has. Nothing could be further from the truth. I have seen many organizations instinctively hoard software, because they think software in general has intrinsic value, even though they have no marketing or sales organization whatsoever. In fact, the software is contributing nothing to their bottom line at all, but they still won't release it, because it's "theirs".

What if the value comes from something else? What if the value doesn't come from the software itself, but instead comes from the domain expertise of your organization or your developers? What if the value comes from the way in which you know how to use the software? There are all kinds of sources of value that surround software, that don't come directly from it. If that knowledge and those activities are the true source of value in your case, then releasing software as open source can make a ton of sense.

I think people need to ask themselves, "what is the worst thing that could happen?". This often puts everything in perspective. If your software is released into the wild, will someone run away with it and somehow harm your organization? What if they had to share all modifications they made to the software? Chances are, you will be at the centre of the community that grows up around the software.

And if the value is in all those things that surround the software, then being in the middle of that space gives you other benefits and opportunities as people turn to you for expertise and support and leadership. By embracing an open source model, organizations can create value from software that might otherwise be contributing nothing to the organization.

So what did that development team do, that was thinking of open source but didn't sound like they really wanted it? Predictably, they didn't open source their software. But just because they lost an opportunity doesn't mean you can't find one! Look around at the software you are developing, ask yourself how it creates value for your organization if you keep all that code to yourself. In many cases, I bet you'll see that the real opportunities come from the community of users and contributors you haven't met yet.