A successful startup/product company needs to master the art of validating early product ideas quickly and effectively. Whether you are building a product, service or a new feature, the two most important questions to find out early are:

  • are we solving the right problem?
  • if yes, how do we pitch the idea to the target customer to generate a favourable action?

During this session, we'll focus on various safe-fail experimentation techniques used by Lean Startups for quickly identifying and validating the customer's value hypothesis, without having to build the real product. You will leave this session equipped with various MVP design techniques, that will allow you to rapidly discover a viable product/service that delights your customers, without spending a lot of time and effort.

Traditionally, entrepreneurs believed that the only way to test their product/service hypothesis was to build the best-in-class product/service in that category, launch it, and then pray. Most often, products/services fail, not because they cannot be built or delivered. But because, they lack the market-fitment and customer appeal.

To avoid these risks, these days startups are focusing on building a "Minimum Viable Product" (MVP), a product that includes just enough core features to allow useful feedback from early adopters. This reduces the time to market and allows the company to build subsequent customer-driven versions of the product. Hence mitigating the likelihood of wasting time on features that nobody wants. MVPs are typically deployed to a subset of customers, such as early adopters that are more forgiving, more likely to give valuable feedback.

However the problem with MVPs is that companies still spend too much time building stuff and very little time learning. Don't forget the purpose of MVP is validated learning NOT building. This session will give you ideas on how to quickly formulate and test your value and growth hypothesis in a scientific framework using extremely cheap MVP techniques collectively referred to as MVP Design Hacks.

2 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/structure of the Session

  • Quick examples of how 2 companies (startup and an established enterprise) had to find the right market fit the hard way.
  • Need for MVP and how its is different from Design Thinking Flow
  • Quick example of how others have hacked their MVPs and achieved their validated learning for a fraction of the cost
  • Some examples from Edventure Labs (an Tech-Ed startup) - From Vision to 6 Pivots - Our journey and learning 
  • Introducing the big picture - "Vision - Strategy - Hypothesis - Safe-Fail Experiment - Validated Learning Cycle"
  • Simon Sinek's Golden Circle (How great leaders inspire action) and how you can design MVPs to discover the "Why" 

Learning Outcome

  • Redefine MVP & understand that you don't have to build even a mini-version of your product to validate your hypothesis
  • Learn how to maximise your validated learning for minimum investment
  • Understand the importance of Safe-Fail Experiments and a few ideas on how to design them
  • Learn the "Vision - Strategy - Hypothesis - Safe-Fail Experiment - Validated Learning" Cycle
  • Understand how MVPs can be designed to discover the "Why" (based on Simon Sinek's Golden Circle)

Target Audience

Product Owners, Product Managers, Sr. Management, Startup Founders

schedule Submitted 2 years ago

Comments Subscribe to Comments

comment Comment on this Proposal

  • Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    45 Mins

    On Agile teams, collaboration is the way of life. Our leaders want their team members to work closely with each other, have shared goals and even think as one entity. Why? Because we believe that collaboration leads to happier, more productive teams that can build innovative products/services.

    It's strange that companies use the word collaboration very tightly with innovation. Collaboration is based on consensus building, which rarely leads to visionary or revolutionary products/services. Innovative/disruptive concepts require people to independently test out divergent ideas without getting caught up in collaborative boardroom meetings.

    In this presentation, Naresh Jain explores the scary, unspoken side of collaboration and explains in what context, collaboration can be extremely important; and when it can get in the way or be a total waste of time.

  • Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    45 Mins

    As more and more companies are moving to the Cloud, they want their latest, greatest software features to be available to their users as quickly as they are built. However there are several issues blocking them from moving ahead.

    One key issue is the massive amount of time it takes for someone to certify that the new feature is indeed working as expected and also to assure that the rest of the features will continuing to work. In spite of this long waiting cycle, we still cannot assure that our software will not have any issues. In fact, many times our assumptions about the user's needs or behavior might itself be wrong. But this long testing cycle only helps us validate that our assumptions works as assumed.

    How can we break out of this rut & get thin slices of our features in front of our users to validate our assumptions early?

    Most software organizations today suffer from what I call, the "Inverted Testing Pyramid" problem. They spend maximum time and effort manually checking software. Some invest in automation, but mostly building slow, complex, fragile end-to-end GUI test. Very little effort is spent on building a solid foundation of unit & acceptance tests.

    This over-investment in end-to-end tests is a slippery slope. Once you start on this path, you end up investing even more time & effort on testing which gives you diminishing returns.

    In this session Naresh Jain will explain the key misconceptions that has lead to the inverted testing pyramid approach being massively adopted, main drawbacks of this approach and how to turn your organization around to get the right testing pyramid.