BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Lessons Learned from Innovating at Google: Frame the Problem, Use Data, and Define the MVP

Lessons Learned from Innovating at Google: Frame the Problem, Use Data, and Define the MVP

Leia em Português

This item in japanese

The truly great, innovative, useful ideas come mostly from two sources: your target users, and people working in the organization - not necessarily those with a "product manager" hat, said Yariv Adan at the Agile Greece Summit 2019. Experimentation can help us to materialize ideas into actual products and technology, but before we do that we have to decide which ideas to try out. Framing the problem, using data, and defining the minimum viable product (MVP) can help us to increase the chance of success in innovation.

Our role is to focus on the users and own the problem; we shouldn’t obsess over our solution. Instead, we should constantly check whether the problem was solved for our users in the best possible way, and as we observe that, new ideas and needs will reveal themselves, argued Adan. "These are ideas and needs you could never come up with yourself, from the ivory tower where brainstorming takes place," he said.

Regarding the ideas coming from people in your organization, often these won’t be senior people or even product managers, said Adan. He mentioned that it will be the people who are most connected to the harsh reality - the products, their mechanisms, and the users. Often, these will be fairly junior engineers, and customer support / account managers, he said.

Adan suggested that the role of managers is to make sure data and communication flow in the organization such that the employees have enough strategic context to understand what is it that the company is triying to achieve, and that there exist effective communication channels for them to provide their insights, regardless of job level, and without being filtered and misinterpreted by layers of hierarchy.

There is no way to be sure which ideas are worthwhile to try out and experiment with. As Adan stated: "I haven’t found yet a reliable crystal ball." He mentioned a few good practices that can increase our chance of success:

  1. Make sure you have an articulated framing of the user problem you are targeting. Entrepreneurs often get overly excited and attached to the "coolness" of their solution - its ingenuity, technical innovation, or design appeal. However, the real value for your users is whether you solved a problem for them. Ideally, one that is otherwise hard to overcome. So make sure you start with a clear focus on a real, big, growing, unsolved user problem.
  2. Make data your decision currency - data, not opinions or job levels, should be used to decide whether you go in one direction or another. This means you define what the measurable goals you are targeting are (covering quality, engagement, and user satisfaction), make it so that you have the technical infrastructure to measure these in experiments, and optimize your product ask to maximize these metrics. Clearly, this doesn’t replace healthy common sense and critical thinking.
  3. Most critical - based on the above, define your MVP - the bare Minimum Viable Product. Be ruthless in cutting out features and UIs that aren’t 100% critical to the core user value you are targeting. Get that version to the hands of users as early as you can, and iterate from there.

Adan mentioned that as we attempt to solve a user problem, we will often discover that we oversimplified it, and that our solution only addresses parts of it, or is even blocked by other related problems we didn’t even consider. "Don’t be discouraged," he said, "these problems are your friends, your requirements, your added value opportunities." He suggested to not get too attached to any specific solution, but instead obsess over the problem.

Yariv Adan, product lead at Google Assistant, spoke at the Agile Greece Summit 2019 about Innovation at Scale at Google. InfoQ interviewed him about framing user problems.

InfoQ : You mention that it’s important to have an articulated framing of the user problem you are targeting in order to decide which ideas are worth trying out and experimenting with. Can you give an example of this?

Yariv Adan: One example I like talking about is Google search - because everyone is so familiar with it. When Larry and Sergey first launched Google, their solution and big innovation was a new way to rank the results, and indeed it was magical. But they very quickly discovered this was not enough.

Users still couldn’t get to the content they were looking for - and it had nothing to do with ranking. When they looked at users’ search queries they discovered that users had spelling mistakes, and that prevents them from getting the right content. So they launched auto spell correction and "did you mean?" Then they found that some users simply don’t know how to formulate their query, so they launched search suggestions. Then they noticed that some data is simply missing from the web, so they launched maps, news, image search, books, etc.

None of these solutions were in their original plan, and it’s highly doubted they would have come up with these themselves. But it’s these innovations and many others that made Google search what it is. It couldn’t have happened without owning the problem, and listening carefully to users.

InfoQ: How are ideas incorporated into the actual products and technology?

Adan: Ideally, you find a quick and lightweight way to test ideas and assumptions, before they make their way into the product. The guiding principle is to incorporate user feedback into your dev process as early as possible (and make sure you have a way to measure and analyze it) - this could be any of:

  1. Qualitative small scale user studies to validate assumptions and get direct feedback on needs, product and UI. This could be done with simple prototypes and mocks.
  2. Sanity test pre-alpha versions of the core user value - within the team / company - this allows you to focus on the core features, not worry about scale, distribution, discovery, and even ignore known issues and missing functionality that isn’t blocking the critical features.
  3. Run quantitative A/B experiments in production for a small %ile of users - monitoring your success metrics and optimizing.

Often, you would go through 2-3 of these before you fully launch a feature.

InfoQ: What have you learned from doing innovation at Google?

Adan: Some of the things that I have learned are:

  1. Innovation can’t be ordained. However, you can create an environment where it will evolve and flourish organically. Fostering innovation requires significant and ongoing company-wide investment, the key pillars being:
    1. Hire the right people and recognize innovation
    2. Have a mission that inspires innovation
    3. Have an empowering environment - that’s the most important element, and what my talk is about.
  2. Great ideas come from:
    1. Involving your users in the process:
      1. Focusing on users and their problems
      2. Getting products early into the hands of users, and seeking feedback
    2. Involving the broader organization / company in the process:
      1. Create an open environment where ideas can flow freely
      2. Use data as the decision currency
      3. Empower people to pursue ideas
  3. Innovation is disruptive by nature - allow disruption:
    1. Encourage and support risk-taking and failures
    2. Allow flexibility in your processes
    3. Embrace the friction that comes with it

Rate this Article

Adoption
Style

BT