In the process of Customer Driven Development(very well described in "The Four Steps to the Epiphany by Steven Gary Blank"), you go and meet a lot of "customers" to validate your various hypothesis. I have done some amount of that work and This is a list of few things that I don't want to forget when I do it next (some of them are trivial but we *do* miss them)...
1. Have your gadgets, all the devices to take audio/video recordings or pictures, ready. Before turning them on, ask the person if he is comfortable with it.
2. Thank the person for his time and make him comfortable by asking him his day to day activities in business and his role.
3. Tell him why you are there in the first place and what is in it for him.
4. Have it very clear in the mind(you may note them down on paper also) what are the questions you want answered before this meeting is over.
5. If you are getting feedback on a product that you've developed, let them *use* it.. watch their expressions, listen to them and see if it makes sense to them. Do not *tell* them why/how something is good or bad, you're their to know their thoughts and not to *sell* the product to them. The objective for you to speak as little possible and make the other person speak(relevant things) as much possible.
6. Many a times, It happens that the person is saying all the good things about what you have(just because he wants to be good to you) or there are times when you just want to get a sense of pricing for your product. You ask them how much are they willing to pay for it, mostly the answer will be.. "I don't know, Once I use it then I may be able to think of a price." and you say, "Ok, what if it was 1 million $(or some random out of the world price).. would you buy it?".. And its very likely(trust me, I have tried it several times) that the person will say something like, "Oh man, this should not cost more than 2000 $." and you have it. I read this trick in the book mentioned in the start.
7. Its usually a good idea to do one such meeting in a day, so you have time to think, consolidate your findings and store this data somewhere.
Tuesday, August 11, 2009
Saturday, July 18, 2009
quote of the day
"Be so good, they can't ignore you." - Steve Martin
to better understand it, read this pyramid method story.
to better understand it, read this pyramid method story.
Sunday, July 5, 2009
d4d - design for delight
This is one technique to collect seemingly random thoughts from a group of people relevant to a (set of)questions/idea/problem/... and coming to a (small set of)conclusion.
For example, let say we want to discuss "Why do monkeys like banana?" and we got people with lots of answers of it. Then, this will be the d4d way of getting the conclusion.
1. Give every body some sticky notes, Ask them to write all their thoughts on those notes(one answer per note) and stick them on the wall.
2. Now make groups of similar answers(stick the notes containing similar answers together, make clusters).
3. Now, we have a systematic way to carry forward the discussion centred around answers received.
4. Discuss as a team and try to reach a conclusion
Note: This is probably the most amateurish way of describing what d4d is :), but this is how I interpret my understanding of it. I'll update this post(if needed) once I get to know more about it.
For example, let say we want to discuss "Why do monkeys like banana?" and we got people with lots of answers of it. Then, this will be the d4d way of getting the conclusion.
1. Give every body some sticky notes, Ask them to write all their thoughts on those notes(one answer per note) and stick them on the wall.
2. Now make groups of similar answers(stick the notes containing similar answers together, make clusters).
3. Now, we have a systematic way to carry forward the discussion centred around answers received.
4. Discuss as a team and try to reach a conclusion
Note: This is probably the most amateurish way of describing what d4d is :), but this is how I interpret my understanding of it. I'll update this post(if needed) once I get to know more about it.
Tuesday, June 30, 2009
my experience with CDI
In the product development world, there are "mainly" two forms of innovation.
1.Customer Driven Innovation(CDI)
2.Technology Driven Innovation(TDI)
As the names suggest, TDI is all about coming up with a solution to a known problem using a very novel technology(might also be invention of new technology) and CDI is more about finding the right problem that needs a solution.
CDI is a very broad topic and there is no one fixed answer to what it is, What I'm about to write here is just my experiences. CDI is one methodical way of conceptualizing and building something that people are likely to use but not an exclusive epitome of creating money-minting products.
For the last couple of months I've been part of researching the business needs of typical small business owners in emerging markets and to conceptualize a product around them. This is where I got some grounding with CDI techniques.
Ideation:
Usually, you start with a very high level sense of a set of ideas and there are two formal techniques to narrow down the choices.
1. D4D(Design for Delight): Here we ask everyone in the team to write down their good/bad thoughts on sticky notes and stick them against respective idea. So basically against every idea we get a list of goods/delighters and bads.
2. Brainstorming: Above session is followed with a long brainstorming session where every thought received above is discussed collectively and agreed upon.
Once we're done with above, its time to make visits to the target audience(customers) and further drill down the high level idea. This is where the CDI starts, you are talking to/observing the customer and constructing the details of the idea. When you're visiting the customer, Following are some important points at this state to be kept in mind...
1. Watch their (work)activities very closely. Observe very very carefully or maybe try to put yourself in their shoes, lookup the world from their eyes and you might see their business problems.
2. Find out their business priorities and filter the ones where they have problems(or inefficiencies in execution).
3. Find the most important problem they have by sorting them according to the business priority and solving which would make the person happy(and more importantly, for its solution he will be very likely to even pay money)
4. Now design a solution/product(just in concepts) around this problem that solves the problem really really well.
So, Now we have conceptualized a product.
Validation
This is one stage that many people forget about. Most of the times, After conceptualizing the idea, people just create the product with all their might in 8-10 months(or whatever) just to learn that the problem they identified was very real but the the solution(they built) is not quite right to solve it(or not perceived right by the customer). So, one should not forget that its very very important to validate their proposed solution and to fill the gaps(improve the solution) iteratively. And, following is a summary version of CDI techniques for same..
1. Create a UI-prototype(not necessarily in the real software form but some screens or designs on paper are just fine).
2. Go back to your target audience and see how they respond to it, let them show their creativity and allow any modifications if they want to make. Adjust your design according to the feedbacks you receive.
3. Continue iterating step#2 until you come to a fairly stable design.
4. Now, create a running prototype of the product asap and hand it over to a couple of people from your target audience to get a taste of it.
5. Take their feedback about the product, adjust it again and hand over the new version.
6. Keep repeating step#5 until you come to a point where your target audience is really happy with the prototype and *ready to pay* for it. Then we're done here.
Productization
This is a fairly well known stage. Following are few things we should keep in mind at this early stage of building the product.
1. Durable Competitive Advantage: What is the competitive advantage built into the product that noone else can copy and catch up with you.
2. Stickiness: If someone else replicates the product, why users would not be easily able to migrate from you. This brings in the "services" aspect in the product.
3. The viral effect: Can you build some feature in the product so that it automatically spreads itself(not spread as in virus but it should be easy for one user to talk about it to others and very easy for others to get it). It should be easy in the product to leverage word-of-mouth marketing.
4. It should not have chicken-or-the-egg problem. That is, it should not be that for your product to succeed, it needs mass adoption from two communities and one community is not going to adopt it unless you have enough adoption from other community. The only way this can succeed then is that somehow you force one community to adopt it and others will follow automatically, but this is usually very hard to achieve.
5. Have a business model ready, there should always be a very good answer to the question, "Why and Who is gonna pay for it?".
1.Customer Driven Innovation(CDI)
2.Technology Driven Innovation(TDI)
As the names suggest, TDI is all about coming up with a solution to a known problem using a very novel technology(might also be invention of new technology) and CDI is more about finding the right problem that needs a solution.
CDI is a very broad topic and there is no one fixed answer to what it is, What I'm about to write here is just my experiences. CDI is one methodical way of conceptualizing and building something that people are likely to use but not an exclusive epitome of creating money-minting products.
For the last couple of months I've been part of researching the business needs of typical small business owners in emerging markets and to conceptualize a product around them. This is where I got some grounding with CDI techniques.
Ideation:
Usually, you start with a very high level sense of a set of ideas and there are two formal techniques to narrow down the choices.
1. D4D(Design for Delight): Here we ask everyone in the team to write down their good/bad thoughts on sticky notes and stick them against respective idea. So basically against every idea we get a list of goods/delighters and bads.
2. Brainstorming: Above session is followed with a long brainstorming session where every thought received above is discussed collectively and agreed upon.
Once we're done with above, its time to make visits to the target audience(customers) and further drill down the high level idea. This is where the CDI starts, you are talking to/observing the customer and constructing the details of the idea. When you're visiting the customer, Following are some important points at this state to be kept in mind...
1. Watch their (work)activities very closely. Observe very very carefully or maybe try to put yourself in their shoes, lookup the world from their eyes and you might see their business problems.
2. Find out their business priorities and filter the ones where they have problems(or inefficiencies in execution).
3. Find the most important problem they have by sorting them according to the business priority and solving which would make the person happy(and more importantly, for its solution he will be very likely to even pay money)
4. Now design a solution/product(just in concepts) around this problem that solves the problem really really well.
So, Now we have conceptualized a product.
Validation
This is one stage that many people forget about. Most of the times, After conceptualizing the idea, people just create the product with all their might in 8-10 months(or whatever) just to learn that the problem they identified was very real but the the solution(they built) is not quite right to solve it(or not perceived right by the customer). So, one should not forget that its very very important to validate their proposed solution and to fill the gaps(improve the solution) iteratively. And, following is a summary version of CDI techniques for same..
1. Create a UI-prototype(not necessarily in the real software form but some screens or designs on paper are just fine).
2. Go back to your target audience and see how they respond to it, let them show their creativity and allow any modifications if they want to make. Adjust your design according to the feedbacks you receive.
3. Continue iterating step#2 until you come to a fairly stable design.
4. Now, create a running prototype of the product asap and hand it over to a couple of people from your target audience to get a taste of it.
5. Take their feedback about the product, adjust it again and hand over the new version.
6. Keep repeating step#5 until you come to a point where your target audience is really happy with the prototype and *ready to pay* for it. Then we're done here.
Productization
This is a fairly well known stage. Following are few things we should keep in mind at this early stage of building the product.
1. Durable Competitive Advantage: What is the competitive advantage built into the product that noone else can copy and catch up with you.
2. Stickiness: If someone else replicates the product, why users would not be easily able to migrate from you. This brings in the "services" aspect in the product.
3. The viral effect: Can you build some feature in the product so that it automatically spreads itself(not spread as in virus but it should be easy for one user to talk about it to others and very easy for others to get it). It should be easy in the product to leverage word-of-mouth marketing.
4. It should not have chicken-or-the-egg problem. That is, it should not be that for your product to succeed, it needs mass adoption from two communities and one community is not going to adopt it unless you have enough adoption from other community. The only way this can succeed then is that somehow you force one community to adopt it and others will follow automatically, but this is usually very hard to achieve.
5. Have a business model ready, there should always be a very good answer to the question, "Why and Who is gonna pay for it?".
Wednesday, April 29, 2009
what is meant by third party platform evaluation
Today I got into an interesting conversation with one of my colleagues(Bala Dutt) about what exactly are we supposed to do when evaluating a third party(open source or commercial) platform. So here it is...
* moscow = must have, should have, could have and wishes
** filling the gap can sometimes also mean negotiation with the project management :)
- Write down all the requirements(as precisely as possible) for which you're evaluating the solution.
- If possible, classify the above requirements into moscow*
- Test the solution against above requirements on some dummy data (here we actually use,install and run the software or use the code or whatever, the platform to solve some problems which correspond to our requirements)
- Now we should be able to give some subjective/objective comments against each requirement. Basically its the gap analysis i.e. does this solution satisfy our requirements out of the box or is there a gap?, if there is a gap then what is the effort needed to fill** that gap?
- One more thing we can look at how flexible, extensible is it to satisfy any future changes.
- Above information should be enough to make the call :) .
* moscow = must have, should have, could have and wishes
** filling the gap can sometimes also mean negotiation with the project management :)
Subscribe to:
Posts (Atom)
