Product Manager @ Multunus
Manish Chiniwalar is Product Manager at Multunus.
Manish Chiniwalar is Product Manager at Multunus.
Lean Startup is a great process to build new businesses. But when it comes to going from theory to practice, our faith in the process is tested and most often, teams give up to a "seemingly" simple and faster approach of building produces - based on gut feel and seeing what sticks.
It’s a Friday evening. There are two people in the conference room and they have been talking to their laptops for about 15 minutes. Vaidy is the founder and Arun is a Product Manager. At the other end of the Skype call, is an owner of a well-known yoga studio in Bangalore.
Another 15 minutes go by and Vaidy mentions “We’ll charge 5% of all the transactions that go through GoodKarma.”
GoodKarma is an application with a mission to help yoga practitioners grow through deliberate and consistent practice. One of the shorter-term goals of GoodKarma is to help yoga studio owners run their studios better.
The person on the other side gets worked-up “5% is just too high!” Vaidy calmly justifies why 5% is, in fact, a small number for the benefit he is getting.
Another 10 minutes go by. Arun and Vaidy are high-fiving!
They’ve just signed up the 5th customer this month, who’s agreed to start a trial on GoodKarma and be a paying customer.
Vaidy: “We better start building the product, fast!”
In this talk, I'll present our story of building a product using Lean Startup methods. How we went from an Idea to the story above and then shipping the product out. The challenges we faced and how we overcame them.
You have a great idea and you want to get it to existence. How do you proceed?
You know that the key to successful product startup is:
1. Building the right product
2. Moving fast
Here’s what usually happens:
It’s now been up to 6 months to a year since you first come up with the idea. Your analytics just doesn’t have enough traffic yet to tell you what’s working and what’s not! You struggle to have a good picture.
If we met 6 moths ago, and if I told you, I have a time capsule wherein you can travel through time, to the end of the product development and know how your users will react to your product. Would you take it?
Of course, you would!
The time capsule I’m talking about is called the Google Venture’s Design Sprint. It’s a 5-day process to validate critical business assumptions. It uses design thinking and lean startup methods to de-risk your product by better solutions and testing it with 5 real users. At the end of the design sprint, you’ll know what connected with your users and what just didn’t make sense to them.
This process will save you months and months of time spent in meetings, research, design, coding, marketing.
5 Days. Monday to Friday. That's it!
The most common objection people have against User Research is, "People don't know what they want" and they go ahead and quote:
“If I had asked people what they wanted, they would have said faster horses.” ― Henry Ford
He's right! But, that's the wrong question to ask your users!
What if you ask instead, "What do you want to get done with your horses?" or just followed it up with a simple "Why?".
Then people might have told you, "I want to reach the other town faster", "I want to be able to carry more people or more goods", "I want to feel the thrill of speed",...
Then it's your job to figure out "How Might We move more people faster with minimum maintenance and cost?"
Let's take another example,
You: "Will you brush your teeth at night from tomorrow?"
User: "Of course, twice a day!"
People are incredibly optimistic about doing things in the future. A good question would be:
You: "What does your night routine look like?"
User: "I have dinner, clean the kitchen, make the bed, Turn on Netflix, switch night lamp on and fall asleep watching House of Cards"
In this talk, I'll share with you, my learning and experience doing user research.
Get a requirement from a customer with a seemingly good idea for a consumer product. What do you do next?
Do a market analysis, understand the product priorities, estimate the time and cost for releasing the product, negotiate pricing and if all goes start development on the product.
We executed product building engagements in a similar way about 6 months back.
Not any more.
For this product launch, we used a combination of the Lean Startup methodologies like the Lean Canvas and the Design Sprint to validate/in-validate key assumptions all in a span of 5 days - validations that typically take multiple meetings and weeks to complete.
We used our learnings, the prototype and presentation to sign up the first 2 pilot customers.
All without writing a single line of code.
In this presentation, Kuldip and Manish will walk through the experience of using Lean Startup methods and the Design Sprint to validate/in-validate key business assumptions and signing up pilot customers with zero lines of code.
How fast can you go from an Idea to Reality?
From an idea to the time you validate your solution with real users - not friends and family, how long does it take?
In case you are yet to start, how long should you take?
Lean Startup is a buzz-word these days. And for a good reason too - it works! But, there may be times when you get hung-up trying to validate with methods like landing pages, MVPs, MVFs and Interviews. And before you know it, a month has passed by, trying to generate traffic to your landing pages, making sense of analytics and polishing your MVP.
The Google Ventures' Design Sprint is a framework for solving real-world problems through research, ideation, prototyping and talking to real users, in 5 days or less.
How will Design Sprint help?
When we conducted design sprints with our customers, we had some unexpected realizations:
Feature branching has been popular for long, but everyone knows about the “merge hell”, a common issue because of long lived branches or infrequent integration. How do you continuously merge, test and release software with great confidence without spending too much time on merging and fixing conflict issues. That is where Mainline development, one of the key practices of Continuous Delivery, comes into picture and Feature Toggle works in conjunction with the same. Feature Toggle [also referred as Feature Flip, Feature Switch, Feature flag] is a technique which allows you to turn on or off a feature through configuration. Feature toggles gives you the flexibility to toggle features in specific environments i.e. turn on a feature in pre-production environments and turn it off the same in production. This also helps to rollback features, as rolling back is as simple as turning off the feature and deploying.
Many software delivery teams struggle to have a common understanding of "why" a product or feature is being built. The documents such as Project Charter, vision document etc. tries to solve this problem, but it’s common to see such documents exist in the repository, hardly known or read by anyone in the team. And this document rarely gets updated too. Ask your team members what is the goal of the project? You may be surprised to know how many actually know about it.
This is where Impact Mapping comes into the picture. It is a "Strategic planning technique", defined by Gojko Azdic, explained in the book Impact Mapping. It is a very simple technique based on the idea of "asking the right questions" which are:
Fundamental of Impact Mapping is that Impact means a change in behavior of an actor which usually results in a positive impact either by Reduction in the Cost or Improvement in ROI for the business.
The above questions need to be answered by the entire team [the IT team, the business people and any other stakeholders, if any], and avoids the common anti-patterns: