Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

Interview with Ash Maurya – Running Lean

Wednesday, February 19th, 2014

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.

Ash Maurya

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

Running Lean

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

MVP is NOT about Building a Miniature-Version of your Product

Saturday, October 12th, 2013

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.

Vision to Validated Learning

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.

Feature Stub

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.

MVP to Test the effectiveness of using Simulations or Inline Instructions to Teach Kids

Saturday, October 12th, 2013

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.

Experimentation Driven Decision Making Workshop

Tuesday, March 19th, 2013

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.

Learn Measure Build Cycle

(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.

Is the word Startup misleading us?

Thursday, October 18th, 2012

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.”

Agile Evolution

Friday, June 15th, 2012

How has Agile evolved over the last 12 years?

Agile WTF – Way to Fail!

Friday, June 15th, 2012

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?

Limited Red

Sunday, January 30th, 2011

How good are you at limiting red time? .i.e. apply limiting WIP (Work-In-Progress) concept to Programming and Product Development.

What is Red Time?

  • During Test Driven Development and Refactoring, time taken to fix compilation errors and/or failing tests.
  • While Programming, time taken to get the logic right for a sub-set of the problem.
  • While Deploying, downtime experienced by users
  • While Integrating, time spent fixing broken builds
  • While Planning and Designing, time spent before the user can use the first mini-version of the product
  • And so on…

Basically time spent outside the safe, manageable state.

Let it be planning, programming or deploying, a growing group of practitioners have learned how to effectively reduce red time.

For example, there are many:

  • Refactoring Strategies which can help you reduce your red time by keeping you in a state where you can take really safe steps to ensure the tests are always running.
  • Zero-Downtime Deployment which helps you deploy new versions of the product without your customers experiencing any downtime.
  • Continuous Deployment which helps you get a change made to code straight to your customers as efficiently as possible
  • Lean Start-up techniques which helps validate business hypothesis in a safe, rapid and lean manner.
  • And so on…

I highly recommend watching Joshua Kerievsky’s video on Limited Red Society to gain his insights.

Over the years we’ve realized that it always helps to have simple tools to visualize your red time. Visualization helps you understand what’s happening better. And that helps in proactively finding ways to minimize red time.

At Industrial Logic we have a new product called Sessions which helps you visualize your programming session. It highlights your red time.

All I want is One Sticky Feature

Saturday, June 19th, 2010

This morning I got hooked to a new band. I’ve heard the band before and I’ve had others praise the band. It was only this morning, when I stumbled upon a particular song by the band and started enjoying it. After that I went and explore the whole album and other albums. Its been 8 hours and I’ve been tripping on their music.

To think about it, software is kind of same. Usually its one sticky (killer) feature that gets people hooked to a new software. Once they experience that feature, without much push, they discover all kinds of interesting features and innovative ways to use them.

As someone building a new product how do you figure out what that feature would be?

I’m aware of 2 approaches that have worked in the past:

  • Agile/Lean-start-up philosophy: Build sketches (quick and dirty versions) of a few features, put it in the hands of real users and see what might click.
  • Open Source/Eat your own dog food philosophy: Build something that addresses your personal itch and see if others have the same itch.

What other approaches have you seen work?

Who needs a separate QA Team?

Wednesday, January 14th, 2009

Have you come across developers who think that having a separate Quality Assurance (QA) team, who could test (manually or auto-magically) their code/software at the end of an iteration/release, will really help them? Personally I think this style of software development is not just dangerous but also harmful to the developers’ growth.

Having a QA Team that tests (inspects) the software after it’s built, gives me an impression that you can slap inspection at the end of any process and improve the quality of your product. Unfortunately things don’t work this way. What you want to do is build quality into the process rather than inspecting (checking) at the end of your process to assure quality.

Let me give you an example of what I mean by “building quality into the process“.

Back in the good old days, it was typical for a cloth manufacturer to have 10-15 power looms. They would set up these looms at the beginning of the day and let them run for the day. At the end of the day, they would take all the cloth produced by the looms and hand it over to another team (separate QA team) who would check each cloth for defect.

There were multiple sources of defects. At times one of the threads would break creating a defect in the cloth. At times insects would sit on the thread and would also get woven into the cloth creating a defect. And so on. Checking the cloth at the end of the day was turning out to be very expensive for the cloth manufactures. Basically they were trying to create quality products by inspecting the cloth at the end of the process. This is similar to the QA process in a waterfall project.

Since this was not working out, they hired a lot of people to watch each loom. Best case, there would be one person per loom watching for defects. As soon as a thread would break, they would stop the loom, fix the thread and continue. This certainly helped to reduce the defects, but was not an optimal solution for several reasons:

  • It was turning out to be quite expensive to have one person per loom
  • People at the looms would take breaks during the day and they would either stop the loom during their break (production hit) or would take the risk of letting some defects slip.
  • It become very dependent on how closely these folks watched the loom. In other words, the quality of the cloth was very dependent on the capability of the person (good eyesight and keen attention) inspecting the loom.
  • and so on

As you can see, what we are trying to do here is move the quality assurance process upstream. Trying to build quality into the manufacturing process. This is similar to the traditional Agile process where you have a couple of dedicated QAs on each team, who check for defects during or at the end of the iteration.

The next step which really helped fix this issue, to a great extent, was a ground breaking innovation by Toyoda Looms. As early as 1885 Sakichi Toyoda worked on improving looms.

Toyoda Loom

One of his initial innovation was to introduce a small lever on each thread. As soon as the thread would break, the lever would go and jam the loom. They went on to introduce noteworthy inventions such as automatic thread replenishment without any drop in the weaving speed, non-stop shuttle change motion, etc. Now a days, you can find looms with sensors which detect insect or other dirt on the threads and so on.

Basically what happened in the loom industry is they introduced various small mechanisms to be part of the loom which prevents the defect from being introduced in the first place. In other words, as and when they found issues with the process, they mistake proofed it by stopping it at source. They built quality into the process by shifting their focus from Quality Assurance to Quality Control. This is what you see in some really good product companies where they don’t really have a separate QA team. They focus on how can we eliminate/reduce the chances of introduction of defects rather than how can we detect defects (which is wasteful).

Hence its important that we focus on Quality Control rather than Quality Assurance. The terms “quality assurance” and “quality control” are often used interchangeably to refer to ways of ensuring the quality of a service or product. The terms, however, have different meanings.

Assurance: The act of giving confidence, the state of being certain or the act of making certain.

Quality assurance: The planned and systematic activities implemented in a quality system so that quality requirements for a product or service will be fulfilled.

Control: An evaluation to indicate needed corrective responses; the act of guiding a process in which variability is attributable to a constant system of chance causes.

Quality control: The observation techniques and activities used to fulfill requirements for quality.

So think about it, do you really need a separate QA team? What are you doing on the lines of Quality Control?

IMHO, in the late 90’s eXtreme Programming really pushed the envelope on this front. With wonderful practices like Automated Acceptance Testing, Test Driven Development, Pair Programming and Continuous Integration, I finally think we are getting closer. Having continuous/frequent working sessions with your customers/users is another great way of building quality into the process.

Lean Startup practices like Continuous Deployment and A/B Testing take this one step further and are really effective in tightening the feedback cycle for measuring user behavior in real context.

As more and more companies are embracing these methods, its becoming clear that we can do away with the concept of a separate QA team or an independent testing team.

Richard Sharpe made a great interview of Jean Tabaka and Bob Martin on the lean concept of “ceasing inspections”. In this 7 minute video, Jean and Bob support the idea of preventing defects upfront rather than at the end. Quality Assurance vs Quality Control

    Licensed under
Creative Commons License