Remember the dot-com days of Webvan and Pets.com? We took traditional businesses and gave then an online presence. Rapidly acquiring a large customer base was the sole goal of many dot-coms. “If we can get enough users, we can easily figure out how to monetize it.” And all of this made perfect sense expressed in dollars and cents. I know people who melted down Yahoo Finance’s servers by checking for their favourite stocks prices throughout the day, calculating their (paper) net worth in real time. If you were not part of this madness, you were certainly considered stupid.

But then on March 10, 2000, the perspective changed. Suddenly it became clear that this was really a bubble. Without having real profits (or even revenue/cash-flow), it was really just a house of cards. In hindsight, the entire dot-com burst made perfect sense. But why wasn’t this obvious to everyone (including me) to start with?

In complex adaptive system, the causality is retrospectively coherent. .i.e. hindsight does not lead to foresight. When we look back at the events, we can (relatively) easily construct a theory to explain the rationale behind the occurrence of these events. In fact, when we look back, the reasons are so obvious that one can easily be fooled into believing that “Only if we spend more time, carefully analysing and thinking through the situation at hand, we can completely avoid unwanted events in future.” Yet, time and again, we’ve always been caught by surprise and it almost appears to be impossible to predict such events ahead of time. Call it the Black Swan effect or whatever name you fancy.

This effect gives rise to a classic management dilemma – Predictability Paradox(pdf). In the zeal to improve the effectiveness and reliability of software development, managers institutionalise practices that unfortunately decrease, rather than increase, the predictability of the product’s success. Most companies spend an awful lot of effort and money to analyse the past, derive patterns and best practices, set targets and create processes to prevent past failure and produce ideal future goals. If software development was highly structured, if we had a stable environment and we had a good data points from million other projects, this approach might work. But for software development, which is a creative-problem solving domain, with high levels of uncertainty and each project having an unique context, these techniques (best practices) are rather dangerous.

In our domain,

• We need to break the vague problem down into small safe-fail experiments.
• Then execute each experiment in short iterative and incremental cycles.
• We need to focus on tight feedback loops, which will help us adapt & co-evolve the system. (We cannot be stuck with analysis paralysis.)
• We need to probe the system with experiments and find emergent practices.
• And then apply these practices in a given context, for a short duration.
• Speed and Sustainability are extremely important factors.

This is what I mean when I say “Action Precedes Clarity”.

With the increase in the consumer demand and change in the market dynamics, the number of new products that are launched in our market have increased tremendously. The passion of these young entrepreneurs have inspired thousands of young minds to develop new solutions to new/existing problems. However the success of these products are largely driven by the consumer expectation and passion is only a driving force.

Ash Maurya, a serial entrepreneur is running a 2-day workshop about building successful products at Agile India 2014. In this 2-day hands-on workshop, you’ll learn a systematic methodology, developed through rigorous testing of Lean Startup, Customer Development, and Bootstrapping techniques on hundreds of products, that will show you exactly how to build what people want.

He is the founder of Spark59 and also the author of ‘Running Lean’. Currently he is working on his new book ‘The Customer Factory’.

We had a short chat with him to understand his views about building successful products.

1. What is one important lesson that the large enterprises should learn from startups and vice versa?

Bringing a new product to market, whether at a large enterprise or startup, is riddled with extreme uncertainty. Most products fail.

The key to raising these odds is prioritizing learning around what’s riskiest (not easiest) in the business model.

The first phase of the journey is getting to a business model that works. This can be characterized as a “search” problem where speed is key. The best mode of operation here is the startup. Enterprises that want to explore new or disruptive innovation should model themselves after startups.

The second phase of the journey is scaling that business model. This can be characterized as an “execution” problem where systems and processes become increasingly important. Here the startup needs to mature it’s practices and can learn a lot from existing enterprises.

2. How does Lean Startup help companies to deliver a customer centric product?

The job of a business model is to create, deliver, and capture customer value.

The Lean Startup embodies the customer in every part of the process. All experiments have to end in customer learning and you aren’t making progress until you can demonstrate customer value.

It is through this continuous feedback loop with customers that we break the product development silo and build more products that people want.

3. Your Lean Canvas is an excellent tool to help companies articulate their business model in a simple format. Are there any gotchas that companies should be aware when using the Lean Canvas?

The biggest pitfall with any kind of modelling is falling into the analysis/paralysis trap. I recommend time-boxing business model creation to no more than a day and then shifting all the effort to business model validation using the other tools in the Lean Stack suite.

4. India has a budding Startup culture. What would be your advice to startups?

I truly believe we are going through a global entrepreneurial renaissance which represents an incredible opportunity for all of us.

But while we are building more products than ever before, the sad reality is that the success rate of these products hasn’t changed much.

The odds are still heavily stacked against starting a new business and most of these products will unfortunately fail.

The good news is that a lot of these big bang failures can be outright avoided and instead replaced with a more systematic approach to building successful products.

The number one reason why products fail is not because we fail to build what we set out to build but because we waste needless time, money, and effort building the wrong product.

I attribute the entrepreneurs unbridled passion for their solution to be the top contributor to this failure.

The key is shifting your perspective from having more passion about just your solution to having as much (if not more passion) for your customers and their problems.

5. What is the take away from your Running Lean workshop ?

This will be hands on workshop with part lecture and part  hands-on exercises where you will work on moving your business forward using lean techniques.

The first day will be all about modelling your business into a more more manageable and testable framework. While the second day will be all about stress testing this business model through carefully designed experiments.

By the end of this 2-day workshop, you will have an actionable plan for what to do next to move your business or product idea forward.

This workshop has limited seats. Book early to avoid disappointments: http://booking.agilefaqs.com/agile-india-2014#workshops

May be I don’t understand the Lean-startup lingo, but to me a MVP has always been about finding the cheapest, safest way to validate your product hypothesis. Sometimes you might need to build a miniature version of your product or service to test your hypothesis and obtain validated learning. But it is not always necessary or even desirable to build something.

Let’s zoom out for a minute. Let’s say you have an idea or a vision for a product or a service. You devise a series of possible strategies you could use to fulfill your vision. However it is important to acknowledge that each of your strategy is based on a list of hypothesis, which needs to be validated using a series of cheap, safe-fail experiments (via MVPs) to obtain validated learning. Then based on real data, we pivot or persist the direction of the vision. Either ways, you need to constantly keep running a series of experiments with real fast feedback cycles to calibrate/validate your progress/direction.

MVP is a safe-fail experiment. The best MVPs are those which give you maximum validated learning for minimum investment (time, effort & opportunity cost.)

For example:

• NeedFeed used a GreaseMonkey script to quickly validate their hypothesis about their social purchasing app on Facebook – http://vimeo.com/24749599
• At EdventureLabs we used presentations to create quick videos to test different learning techniques and their retention power with kids.
• Or we used dummy meters to validate the business model of an energy company, which wanted to build energy saving products for rural India. We visited a few farmers and small factories, explained how the device (dummy meter) would save them 50% on electricity bill each month. We quickly discovered that our business model was flawed and surprisingly we co-created a better model. Also through this process we learned about certain key concerns these folks had which required a very different conceptualization of the product.

Your ability to quickly (almost on the fly) tweak a little parameters and quickly test a corollary hypothesis is another very important characteristic of an MVP.  This is extremely important because when you go out there in the field to run your experiment, in the moment, you might find new data or ideas which might need to be validated to solidify your validated learning. If you have to make code changes and deploy stuff, it might not be easy for you to test new hypothesis, right then and there. Which is very important IMHO.

Next time you think of a MVP, think about a cheap, safe-fail experiment you can run to validate your hypothesis.

Note: Its important to distinguish MVP from Features Stubs. Feature stubs are also a quick way to validate your hypothesis, however they are mostly applicable once you have a product and want to validate how useful certain feature might be.

For example: Recently, I wanted to test if liking a comment on the Agile India Submission system is a feature people would find useful.

I added a like button which would simply show an alert message saying “Coming Soon..”. Using Google Analytics, I was able to measure that out of 36,000 impressions, only 6 people clicked on the Like button. A cheap way to validate my hypothesis. But this does not affect my product strategy and hence its different from MVP.

At EdventureLabs, we were trying to teach kids age (5-7,) to represent numbers on the Abacus. First we created a small animation video with a little story line. We took help of a professional animation expert. However, we quickly realized that kids have very little attention span and if they are not able to interact with what they are seeing on the screen, they quickly (in less then 30 secs) zone-out. Also animation was expensive and had a huge turn-around time even if we wanted to make a small change. Clearly a bad strategy.

Inspired by lot of mobile games, we came up with a hypothesis that if we created inline instructions and used micro-simulations, then the kids would have a better retention power and hence be able to learn much better. We wanted to quickly test this hypothesis.

However we had not yet built an app, so building an app and creating a simulation would take us a few days. But we wanted to quickly test the simulation hypothesis to see its effectiveness. So we took a short-cut.

We quickly (in less than 10 mins) found a bunch of images on the net, created a presentation and added a bunch of transition to create an animation effect. Then we exported this presentation out as a movie.

Now the kids were able to watch this 10 second movie, like they would see a simulation/inline instruction in our app. Once the simulation showed how to represent a number, we would ask the kid to move the right beads on the abacus. Of course the beads would not move, but we would be able to test whether the kids tried to move the right beads and hence assert if they remembered how to represent number. If they could, we would ask them to represent other numbers which were not shown in the simulation to see if they can extrapolate what they just learned and apply the logic for other numbers. Most kids could do simple numbers, but were not able to do all the numbers. Another good learning from this experiment.

Anyway, here is the very first video we created to test our simulation hypothesis.

Why do we see new process or methodology or movement every 10 years or so?

Using the Adaptive Change Cycle we can easily explain the rationale behind it.

In the last couple of months, I’ve got several requests from top-notch product companies in India, asking me to facilitate a hands-on workshop on decision making using Lean-Startup’s hypothesis validation techniques for their Executive and Senior Management. I’m thrilled to know that companies are seriously exploring these options.

Following is a 1-Day workshop which I’ve successfully ran a few times:

Experimentation Driven Decision Making Workshop

Large number of products/services fail today, not because they cannot be built and delivered, but because the entrepreneurs building those products/services are disconnected from the people consuming them. This disconnect, leads to early assumptions about consumer’s behavior and motivations. To one’s surprise, these decisions can turn out to be based on stupid (read as: deadly and risky) assumptions.

Traditionally, entrepreneurs believed that the only way to test their product/service hypothesis was to build the best product/service in that category, launch it, and then observe user behavior. And of course the big bucks spent on marketing campaigns. Surprise! Surprise! This can be a very time consuming & expensive process; not to mention the huge opportunity cost.

(src: Kent Beck)

Luckily today, we know that many entrepreneurs are using Lean-Startup methodology’s Customer Development practices to help them make important product/service decisions (cheaply) based on Validated Learning.

This workshop will give you a hands-on experience to formulate and quickly test out your value and growth hypothesis.

Process/Mechanics

This is a group activity and the participants have to work in small groups.

In the first one hour of the workshop, each group has to come up a product/service idea, which they believe will really succeed. Then they craft out the elevator pitch about the product/service and put together a basic business model. Post that, the group has to clearly highlight what are their value and growth hypothesis.

The rest of the workshop is dedicated to the participants trying to validate their hypothesis. They can use phone and/or Internet to do their research and validation. The best results, of course, are got when the participants meet real people face-to-face to validate your hypothesis. I’ve seen participants wait outside restaurants, cafes, health-clubs, malls, etc. to run their tests. Some participants also get really creative and build some paper prototypes or fake products to validate their hypothesis. Using a fake credit card swiping machine to see if people will really pay is one of my favorite validation techniques so far.

It always amazes me how creative people can get during this process. Also it’s very fulfilling to see the “Aha moment” on the participant’s face. I can’t describe in words, the shocked look on their faces, when they spend the day validating their hypothesis and discover various hidden assumptions about their target user’s behavior.

Learning Outcome

• Learn how to decide which assumptions you MUST absolutely test.
• Understand why just marketing metrics won’t help you make a better product/service.
• Master the art of leveraging the Minimum Viable Product to create maximum validated learning for minimum cost.
• Learn how to systematically decide when to Pivot to a new strategy.

Workshop style

Interactive dialogues, case studies, hands-on group activities, and on-field exercise.

For a minute, if we replace the word startup with business (early-stage-business, if you insist.) What have we lost? Does the word startup really bring anything extra to the table?

If we look at Eric Ries’ definition:

A startup is a human institution designed to deliver a new product or service under conditions of extreme uncertainty.

I would say every business has uncertainty. Extreme or not is a matter of perspective & approach.

I remember reading a while ago about Start a Business, not a Startup on 37 Signals‘ blog Signal vs. Noise. Now I understand what they really meant.

I’m planning to pretty much do away with the word startup and instead just call it business.

This will really help me focus on the hard-core business aspect of my products and services instead of  hiding behind the feel-good-factor of “startup.”

How has Agile evolved over the last 12 years?

This is an introductory presentation on the essence of Being Agile vs. Following Agile. And why being Agile is important? I’ve also tried to show an evolution of Agile methods over the last 11 years and the future of Agile. Also take a sneak preview into what challenges an organizations may face when trying to be agile?

Good Product Owners are:

• Visionary
• Can come up with a product vision which motivates, inspires and drives the team
• Aligns the product vision with company’s vision or mission
• Passionate Problem Solver
• Should have a knack of identifying real problems and ability to visualize a simple solution to those problems.
• Has good analytical & problem solving skills
• Subject Matter Expert
• Understands the domain well enough to envision a product to solve crux of the problem
• Able to answer questions regarding the domain for those creating the product
• End User Advocate
• Empathetic to end-users problems and needs
• Able to describe the product from an end-user’s perspective. Requires a deep understanding of users and use
• Is passionate about great user experience
• Customer Advocate
• Understands the needs of the business buying the product
• Ability to select a mix of features valuable to various different customers
• Business Advocate
• Can identify the business value and synthesize the business strategy as measurable product goals
• Has a good grasp of various business/revenue models and pricing strategies
• Capable of segmenting the market, sizing it and positioning a product (articulate the Unique Selling Proposition)
• Is good at competitive analysis and competitor profiling
• Able to create a product launch strategy
• Communicator
• Capable of communicating vision and intent – deferring detailed feature and design decisions to be made just in time
• Decision Maker
• Given a variety of conflicting goals and opinions, be the final decision maker for hard product decisions
• Designer
• Possess a deep understanding of (product) design thinking
• Able to work effectively with an evolving product design
• Planner
• Given the vision, should be able to work with the team to break it down into an iterative and incremental product plan
• Capable of creating a release roadmap with meaningful release goals
• Is feedback driven .i.e. very keen to inspect and adapt based on feedback
• Collaborator
• Able to work collaboratively with different roles to fulfill the product vision. Be inclusive and empathetic to the difficulties faced by the members of the cross-functional team
• Given all the different stakeholders should be able to balance their needs and priorities
• Empowers the team and encourages everyone to try new ideas and innovate

Disclaimer: This list is based on my personal experience but originally inspired by discussions with Jeff Patton.

In my experience its hard (not impossible) to find someone who possess all these skills. It requires years of hands-on experience.

Some companies form a Product Ownership team, comprising of different people, who can collectively bring these skills to the table. Personally I prefer supporting one person to gradually build these skills.

I amazed how easily companies get convinced that they can send their employees to a 2-day class on Product Ownership and acquire all these skills to be a certified Product Owner.