Building B2B Minimum Viable Products (MVP)
•
12 recomendaciones•3,610 vistas
Slides from Lean Startup Israel meeting - Lessons learned from building MVP (min. viable product) for validating product roadmap and features in a B2B environment. by Oren Raboy
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Building B2B Minimum Viable Products (MVP)
Similar a Building B2B Minimum Viable Products (MVP) (20)
Más de Totango
Más de Totango (20)
Último
Último (20)
Building B2B Minimum Viable Products (MVP)
- 2. Minimum Viable Product @orenraboy www.totango.com
- 3. You don’t know what you need to build 1 Only customers can teach you 2 Find out before running out of cash 3 @orenraboy www.totango.com
- 4. Maximum Learning Minimum Cost
- 5. Presentation Post Landing Page Mockup Demo Working Code
- 6. Not as Simple as it Sounds! 1. Deciding what to validate 2. Overestimating minimal
- 7. in MVP-Land: 1 Month to first working version 20 Early feedback customers 2 Releases a week What have we learned?
- 9. Lesson I MVP is a process
- 10. Lesson II Focus on what you want to validate
- 11. Lesson III Measure!
- 12. Lesson IV MVP is no excuse for poor design
- 13. RECAP Learn fast, learn often It’s harder than it looks, but gets easier with practice it’s a process not a milestone MVP isn’t a hack – Design It: What do you want to validate? How will you measure it?
Notas del editor
- deals with the following facts-of-life of a startup
- …this is reality, so MVP says “build something to engage”
- “product” is confusing a bit…can be many things.any thing that helps you learn more.Here are some tools that are known in the industry… We’ll share what use in a second.
- fast into the marketlots of customers giving feedbackmany releases so we can iterate fast…
- this is the process we follow:ppt used to validate problemwireframe validate solutionsoftware validate that we got it right. this is the proof in the pudding.
- Validate all 3-steps. Go up & go downexample from a different company: we had an idea, spent 2-3 weeks defining a solution; we weren’t ready to share with potential customers, because we wanted to “be ready”. when we met with customers we had a good architecture view and mock-ups of how we plan to solve the solution; 10-min into the meeting it was clear that the problem we were trying to solve wasn’t real. after a few of these we had good ideas on other things we could do… but we ran out of steam and never followed through…… at @totango, guy&omer were much more diligent in their vision validation process. they spent time going back to their initial industry contacts until they felt they had found a good ‘hole to dig in’ . avoid the urge to dive-deep / “develop-code”; spend time validating visions.
- Email example: got good signalsstarted implementing a “minimal version”… spent lots of time on a email system (scheduling, templating)nobody used it… because we didn’t get the content of the report rightswitch to manual sending… now getting traction.Lesson: wasted time… wasted effort (need to redo entire report system)it’s like code… u need to designfirst, address your bigger riskssame example: give email example where we rushed to implement the mechanism… no one used, the info. wasn’t interesting… spent a lot of time on this. … ended by creating manual reports … quick iterations and now we know… and need to redesign the email engine.
- most important part of the design, figure out what you want to measure in advance….Qualitive vs. Quantativewhat do I want him to say: “agree to beta; connect us with someone [CEO->VP Sales]Quantative: metrics: are people using? we released a few times with out the right instrumentation in place, was really hard to tell if the mvp was effective or not.
- we just found this to be true; when you implement MVP you are doing a lot of “selling”. you need to invest in that; a ppt needs to look nice mockups need to “look real” working code needs to have a polished interfacewithout it, you can’t get your audience’s attention for quality feedback;
- the goal is to learn as fast as you can…not just about the beginning, at any point in your product you can do an MVPMVP are effective when you think them through, not just hack them out… Thinking means: What are we trying to validate, how will we know (measure)