Successfully innovating in large companies

Perhaps I should begin this post by defining what I refer to as ‘innovation’ in the context of this blog post. Innovation is a creative idea; it could be selling an existing product to a new customer segment, using an existing technology in a new context or introducing a new product into a known customer segment. One more important aspect, it provides real value and someone should be willing to pay for it. Ideas are a dime in a dozen, but execution and generating value is where the true challenge lies.

The number of challenges one faces when innovating within a large company is numerous, developing a new product is only meant for visionaries with an appetite for risk taking, unwavering vision, total dedication and time to see it through the tough times.

If you are leading an innovative initiative in a corporate, how can you set your team up for success?

  • Be realistic, very realistic

It is very useful to understand your chances of success and be very realistic about it. Product failure rate is really high, a new research by Harvard Business School shows 75% of all start-ups fail, in short it is a hit and miss proposition. This means that if you have ten ideas, only two are likely to succeed.

While this is a gloomy picture, it would be useful to acknowledge this and ask yourself, how do you reduce your chances of failure?

This leads to the next point………

  • Get out the building and discover your customers

“In a startup no facts exist inside the building, only opinions.”  Steve Blank

The greatest cause of product failures is not in the development of the product itself, but in finding customers. Way too often visionaries are more than comfortable to sit inside buildings and making endless assumptions. ‘Build and it will come’ seems to be the standard motto. This is a recipe for failure.

Steve Blank recommends a ‘customer development’ process that runs in parallel with product development, this involves visionaries getting out of the offices and beginning a process of customer discovery and validation. He also makes the point that products developed with senior management out in front of customers, early and often win. Hand it over to sales and marketing who have not been involved in the product development process loses.

Customer development is really about validating the assumptions that you are making at the earliest, instead of waiting for an official launch.

  • Understand you are in ‘Search’ mode

Working with an existing product and incrementally improving it is very different to new product development and innovation. The rest of the company is often involved with existing products; in this case the business models and market is well understood. This means you can format business plans and forecast growth with a relative degree of accuracy.

However, the same does not apply when creating new products under conditions of uncertainty, endless hours on growth and sales figures are a pure waste of time. The focus should be on searching for a business model that works. The way to do this is to perform small experiments to test out the assumptions, learn from these experiments, then adapt or pivot the business model until it works.

The ‘lean start-up’ methodology works in this ‘search’ mode:

It favors experimentation over elaborate planning, customer feedback over intuition, and iterative design over traditional “big design up front” development.” Steve Blank

Customer development and the ‘lean-startup’ methodology puts customer at the heart of product development and reduces the risk of product failure. Why wouldn’t you follow it?

Backlog Elaboration: A Win-Win Proposition

As we all know, Product Managers are responsible for maintaining the Backlog such that it reflects the demands of the market. As market dynamics change, the backlog changes too. The Agile way of constantly prioritizing the backlog and keeping the most relevant features or stories at the top are key to ensuring that the product stays competitive in today’s dynamic market.

Many times, the Product Manager and the Product Development team go into Sprint Planning without enough clarity on some features or user stories. This causes the planning meeting to go in circles around these user stories without the user stories finally getting picked up for development, simply because there is not enough detail or the Product Manager needs to cycle back with the Business on some clarifications. This causes a delay in the feature being picked up and ripples down to a late deployment.

Despite his/her best efforts to make the stories “development-ready”, how can the Product Manager be sure that (s)he indeed has gathered all the needed information before stepping into the Sprint Planning meeting? This is where the Backlog Elaboration meeting comes in handy. Midway through the Sprint, the Product Manager assembles the team together and presents the priorities for the next Sprint to the team. The team and Product Manager go through each user story briefly and decide if the story is clear, has the necessary information, broken down to a proper size, the wireframes are ready, etc. Once all the information is available, the team can also assign point estimates to the story. The Product Manager and the team perform this exercise for all the user stories tentatively planned for the next Sprint.

Advantages of this exercise.

  • The Product Manager knows if there are any shortcomings in the user stories before the Sprint Planning meeting and has time before the Sprint Planning meeting to collate the required information.
  • The Product Manager has a fair idea before the Sprint Planning meeting about the size of the stories and knows how much might get done (based on the team’s Sprint velocity).
  • The team knows the nature of the user stories coming up and can gear up for them and raise any environment setup or training needs up front.
  • The Scrum Master gets an idea of the kind of challenges the team might face and can prepare to mitigate them up front.
  • The Sprint Planning meetings end up being much shorter and more productive since  most of the stories have been discussed earlier.

Disadvantage:

  • The Elaboration exercise might temporarily distract the team and take them away from focusing on the goal of the current Sprint.

One of the teams that I worked with followed 2 week Sprints, where the Sprint planning would happen on the first day of the Sprint and the Elaboration meeting would happen exactly one week later. Initially, the Product Manager got many inputs from the team on the user stories in the Elaboration meetings. These were taken care of before the Sprint planning meetings. Over time, both the Elaboration and Sprint Planning meetings shrunk in duration and the entire team reaped the benefits of better planning and proper elaboration.

Do let me know if this is something that could work for you.

Product Roadmap: Commitment or Direction?

roadmap exampleA product road-map is a schedule of action items that a product owner believes will help improve market share and/or profitability of his product. This list of action items is compiled by processing inputs from various sources including but not limiting to sales, marketing research group, etc (read Collecting requirements and building radar). Action items include product release in newer geographies, features targeting vertical specific requirements, technology (platform, OS, frameworks etc) upgrades, improvised user experience etc along with time lines. Ideally it is talking about priorities with respect to the product life cycle. Continue reading