Article by me at Medium.

How to reduce Product Development Risk - Reduce your idea to its core function.

How to reduce Product Development Risk - Reduce your idea to its core function.

skip to main |
skip to sidebar
## Friday, March 28, 2014

###
How to reduce Product Development Risk

## Sunday, March 23, 2014

## Thursday, March 20, 2014

###
The Minimum Viable Canvas

## Tuesday, March 18, 2014

###
The Minimum Viable Product

## Labels

My saga in the realm of Software Engineering.

Article by me at Medium.

How to reduce Product Development Risk - Reduce your idea to its core function.

How to reduce Product Development Risk - Reduce your idea to its core function.

Labels:
Minimum Viable Product

To follow this post, please read my earlier post, The Minimum Viable Product, in case you haven't.

The Minimum Viable Canvas is a subset of the Lean Canvas by Ash Maurya. The Lean Canvas itself is an adaptation of Alex Osterwalder's Business Model Canvas. You can read about the two canvas's in Ash Maurya's post here.

The Minimum Viable Canvas is not meant to replace the Lean Canvas or the Business model Canvas. The objective is to split these canvas's into two parts. The "Product" part and the "Market" part. For me this was easily done with the Lean Canvas, so that is why the Minimum Viable Canvas is a subset of the Lean Canvas.

The proposition I am making here is that the two part's have to be done by two separate persons/teams. It can be done by the same person/team also, if the are strong in both product development and customer development. Also, it has to be done in order. First the product part, then the Market part.

The Minimum Viable Canvas will use the iterative procedure as required by Steve Blank's__Lean Startup Approach__.

So how did I come about this? In the last three our four months I have been learning about lean startups almost full time. Read books, articles, studied actual cases and so on. I must have studied over a hundred cases in detail. Here is what I observed.

The Minimum Viable Canvas is a subset of the Lean Canvas by Ash Maurya. The Lean Canvas itself is an adaptation of Alex Osterwalder's Business Model Canvas. You can read about the two canvas's in Ash Maurya's post here.

The Minimum Viable Canvas is not meant to replace the Lean Canvas or the Business model Canvas. The objective is to split these canvas's into two parts. The "Product" part and the "Market" part. For me this was easily done with the Lean Canvas, so that is why the Minimum Viable Canvas is a subset of the Lean Canvas.

The proposition I am making here is that the two part's have to be done by two separate persons/teams. It can be done by the same person/team also, if the are strong in both product development and customer development. Also, it has to be done in order. First the product part, then the Market part.

The Minimum Viable Canvas will use the iterative procedure as required by Steve Blank's

So how did I come about this? In the last three our four months I have been learning about lean startups almost full time. Read books, articles, studied actual cases and so on. I must have studied over a hundred cases in detail. Here is what I observed.

- The person/team have a good problem to solve, and come up with a solution and value proposition that is not unique.
- The team has a good problem and unique value proposition, but still come up with a solution that is not unique. This is like the wrong way of going about it, I discussed in my previous post.

I also observed that this has something to do with how technically strong the team.

- If the team is not technically strong, there is a high probability that they would end up in either of the two situations described above.
- The team is technically strong and still ends up in either of the two situations above. This, I observed may be due to the team getting distracted by the "Market" side of things. They are not focussing enough on the "Product" side.

The Minimum Viable Canvas is my attempt at a solution to the problem. And this is how it should work.

- Initially, the team must work on the Minimum Viable Canvas only, until they arrive at the Low Fidelity MVP, or High Fidelity MVP, MVP, whichever may be the case, depending on their technical capabilities and the complexity of the problem.
- They should know how they are going to "make" the MVP. (I have discussed this in the last post). They should write a one page brief on how they are going to "make" the solution.
- The solution must result in, or comply with, a unique value proposition. (I have discussed this in the earlier post). This is an iterative process until you arrive at the solution and unique value proposition.

Once you have the Minimum Viable Canvas right, you can move on to the Lean Canvas, or Business Model Canvas. If it is the lean canvas, just fill up the equivalent sections. And you will now have a Canvas with the "Market" side of things blank. Now the marketing team takes over and works on the rest of the canvas, and validates the hypothesis. Again this is an iterative process. If you are wrong and need to pivot, start with the Minimum Viable Canvas again.

I have seen many teams trying to do a better tripadvisor, or better flipboard/newsreader. Some taking an existing solution and improving upon it by adding AI/ML to it. Unfortunately almost all of them were going about it the wrong way, as discussed in my earlier post. The Minimum Viable Canvas tries to constrain the team into only thinking of the problem, solution and unique value proposition. Thus, they can improve their chances of coming up with the optimal solution.

I have seen many teams trying to do a better tripadvisor, or better flipboard/newsreader. Some taking an existing solution and improving upon it by adding AI/ML to it. Unfortunately almost all of them were going about it the wrong way, as discussed in my earlier post. The Minimum Viable Canvas tries to constrain the team into only thinking of the problem, solution and unique value proposition. Thus, they can improve their chances of coming up with the optimal solution.

The Minimum Viable Canvas is a **Product** focussed canvas. The order in which to work on the canvas is as follows.

- Problem
- Unique Value Proposition
- Solution
- Cost Structure
- Key Metrics (How are you going to test the value proposition?)

You must also write a one page brief on how you will make the minimum viable product. And how you will test the value proposition against it.

Labels:
Minimum Viable Product

For those not familiar with this subject here is a link.

There has been, a lot talked about the minimum viable product (MVP). There are a lot of articles discussing it's pros and cons. In this post I want to do a different take on this subject. The opinions expressed here are my own. I am writing all this based on my experience.

Quoting from an article on Apple designer Jonathan Ive from Time.

**“Objects and their manufacture are inseparable. You understand a product if you understand how it’s made,”**

He was talking about hardware. But this can also be applied to web based products and services. And also other areas too, I think. Here, we will only look at web based products and services.

So let us rewrite the above quote for web based products.

**A value proposition and it's MVP are inseparable. You understand a MVP if you understand how it is made.**

Sounds so simple. Then, why do we go wrong over and over again? To answer this question let us look at some examples.

Let's say we have a value proposition. We can build a better search engine than Google and Bing. These search engines have a problem. We will call it Problem X. We have the solution to problem X. And here is our plan of action to build our MVP.

First we build a search engine that works like Google and Bing. Next we add our solution to Problem X, to it. And we have a better search engine. Wrong! This is the wrong way to go about it.

The right way to go about it is, to solve Problem X first. And build a search engine around it. In fact this is exactly what Google did. A lot has been written about it, so I will not go into that here. When Google first launched, they did not try to emulate the other search engines of the time. Instead they started with their solution to Problem X and built the search engine around it. And this is also the reason why Bing is not better than Google. Bing simply did not have a Problem X to start with.

The example above was an extreme case. Let us look at a real life scenario. There is a marketing person. He knows for sure people have a certain problem. Problem X. He has a value proposition. But no solution to Problem X. He knows this is a problem worth pursuing. And he needs a software engineer to build the MVP.

If the software engineer builds the MVP without the solution to Problem X, with the hope that he can add the solution later, he is doing it wrong.

**A value proposition and it's MVP are inseparable.**

The software engineer can start with the solution to Problem X, only if he knows the solution. He can know the solution only if he knows how to make it.

**You understand a MVP if you understand how it is made.**

So as an entrepreneur, how do you know if your software engineer has come up with the optimum solution?

**Problem -> Solution -> Unique Value Proposition**

If your software engineer has come up with a solution, that produces a value proposition similar to your competitors, he has got it wrong. His solution must produce a Unique Value Proposition.

**It is all about the "Jonathan Ive" in your team.**

There has been, a lot talked about the minimum viable product (MVP). There are a lot of articles discussing it's pros and cons. In this post I want to do a different take on this subject. The opinions expressed here are my own. I am writing all this based on my experience.

Quoting from an article on Apple designer Jonathan Ive from Time.

He was talking about hardware. But this can also be applied to web based products and services. And also other areas too, I think. Here, we will only look at web based products and services.

So let us rewrite the above quote for web based products.

Sounds so simple. Then, why do we go wrong over and over again? To answer this question let us look at some examples.

Let's say we have a value proposition. We can build a better search engine than Google and Bing. These search engines have a problem. We will call it Problem X. We have the solution to problem X. And here is our plan of action to build our MVP.

First we build a search engine that works like Google and Bing. Next we add our solution to Problem X, to it. And we have a better search engine. Wrong! This is the wrong way to go about it.

The right way to go about it is, to solve Problem X first. And build a search engine around it. In fact this is exactly what Google did. A lot has been written about it, so I will not go into that here. When Google first launched, they did not try to emulate the other search engines of the time. Instead they started with their solution to Problem X and built the search engine around it. And this is also the reason why Bing is not better than Google. Bing simply did not have a Problem X to start with.

The example above was an extreme case. Let us look at a real life scenario. There is a marketing person. He knows for sure people have a certain problem. Problem X. He has a value proposition. But no solution to Problem X. He knows this is a problem worth pursuing. And he needs a software engineer to build the MVP.

If the software engineer builds the MVP without the solution to Problem X, with the hope that he can add the solution later, he is doing it wrong.

So as an entrepreneur, how do you know if your software engineer has come up with the optimum solution?

If your software engineer has come up with a solution, that produces a value proposition similar to your competitors, he has got it wrong. His solution must produce a Unique Value Proposition.

Labels:
Minimum Viable Product

Subscribe to:
Posts (Atom)

- Android (1)
- Clojure (1)
- General (2)
- identity (2)
- Javascript (5)
- jQuery (4)
- Minimum Viable Product (4)
- openid (3)
- Python (1)
- Software Engineering (2)