A blueprint for rapid product discovery 🕵️‍♀️

These past months have been quite a whirlwind for Google, and the Tech Sector at large. As a Product Manager and people manager, these times are among the most formative. When we go through them, we rarely find time to reflect, nor do we grasp the significance of the situation (thankfully, I guess).

When the company laid people off in January, it became clear that this was more than just a headcount reduction. It was also a – very blunt – signal to the product teams where the company felt that business value was lacking. One way to read the impact could be: if we reduce your headcount, we like to signal to you that you should think hard if you should stay invested in this space.

Google has been criticized for making it too easy to start new initiatives, and creating an environment where projects aren’t graded against a fair market perception. Instead, a culture of ‘letting 1000 flowers bloom’ has been created, with little to no mechanism (and incentive) to remove some of the weaker ideas from the batch.

A lot of people in Tech work insanely hard to build something of value to our users. Period.

A lot of people in Tech work insanely hard to build something of value to our users. Period. The fact is, in my experience, that the situation is tough on each end. On one side, folks work super hard to define products and areas of investment which have value. They are being placed into a complex and large high-stakes environment (think only about the consequences of the brand associated with anything you might do, or the caliber of individuals around you). This makes doing anything really complex. On the other side, team members are being met by an increasingly strong need for business value. This might even be articulated quite a distance away from them. In Tech a the newly formed ‘general manager’ structure has been pretty popular as of late, in addition to the multiple layers of VPs and SVPs (not speaking of the additional layers of Directors and Senior Directors). It is like looking at the sky, counting the jets you see fly by at random, and being asked to optimize the destination graph for a specific airline.

How could a self–driven, iterative product development organization survive this? How can you, in light of hyper-fragmentation (both locally, but also in terms of timezone), and hyper flexibility (changing teams at Google has been very easy for engineering and product teams until recent) expect anyone to deal with the complexities of net-new product discovery? Let’s pause here and recognize: even for a small, co-located, non-fragmented, empowered, lean, low-org complexity team doing good and fast product discovery is incredibly hard.

Even for a small, co-located, non-fragmented, empowered, lean, low-org complexity team doing good and fast product discovery is incredibly hard.

While I have certainly seen people surrender to elevated levels of cynicism, this isn’t a long-term approach to the situation. While things are complex, there is a lot of good that can be done. So, as Product Managers, how can we go about it? This following section is a practical idea which was born out of many hours of brainstorming, and collaborated on across many teams, with a great deal of input from many people. It worked incredibly well, and helped us carve out a space in which we could ‘act like the Google of old’ as many folks on the team used to say. I don’t quite know whether I even know what that means. But it was fun, in light of difficult times, and generated value. What more can you ask for?

A Product Discovery Blueprint

The elements of this blueprint are simple, and that might be in part why it worked.

• A mission statement: this guides what you are after. It is an art to create a good one, but it must not be complicated. In the absence of something magical (like Google’s ‘organize the world’s information’), start with something pragmatic. We used ‘Help Googler’s learn’ for example. Simple, pragmatic, and directly related to the job our team is set up to do.
  
• Define the space you want to operate in: Product teams often suffer from scope creep, the idea that more features have more value. Often that isn’t the case, and it can actually create a significant amount of risk to let scope be undefined, or defined too broadly. Start small, and always be specific. For us, we chose the learning space which is non-transactional, and mostly oriented toward internal technologies.
  
• Principles (aka razors): Arguably the most important part. Through principles you can create an environment where teams can ideate and become self-accountable for selecting ideas. If they meet the principles, the idea is worth talking more about. If they don’t, the idea is probably not suitable for the space you created. We defined 5 principles, which all helped filter ideas. Some folks were upset. I found this a good signal: we created boundaries, and they worked. Most folks on the team should buy into these boundaries, as otherwise they’ll likely disengage.
  
• A clear and simple working model: You don’t have to reinvent the wheel here, but helping teams understand how to create a good hypotheses, how to write up the basic elements of the idea etc is the minimum. You might be in a place where the existing working model is a good fit, or need minor adjustments. We carved out some new additions, such as ‘safe to fail experiments’, and a lightweight template for capturing our ideas.
  
• Phases: Gamify the system, and let folks work toward ‘unlocking the next level’. An idea is good (level 1), a documented idea which meets the principles is better (level 2), a staffed documented idea can make progress on data generation (level 3), and data proving value is ready for formal prioritization (level 4).
  
• Define a clear outcome you are shooting for: It is key that folks know what they are in for. In most cases, some iterative product discovery needs to develop a ‘failure culture’. This means to tolerate and celebrate attempts to generate new data, even if this data indicates that the idea is not worth pursuing. We call them ‘failed pilots’, but we celebrate the data they generate. We share the data broadly, across the teams and beyond organization boundaries.

Summary

Owning the situation, and reflecting on it honestly by acknowledging the constraints you operate under is key. Often, in Tech and elsewhere, we just put out the goals, and don’t collaborate on the working model, principles, and other aspects which are critical for success. We spend too much time in ‘wishful thinking mode’. I am glad to see that most teams I work with are still willing and able to engage in the mode which is production, unlocks value to users, and leverages the exceptional talents of my company.

Take Action 🎬

📅 If you ever have any questions, feel free to book time with me for a quick PM consultation session.

📚 To learn the foundations of Product Management, I recommend reading INSPIRED by Marty Cagan. Marty has been leading the Silicon Valley Product Group for over two decades. His work is foundational for Tech Product Managers – a must read.

📚 For iterative product discovery, check out Continuous Discovery Habits, by Teresa Torres. It presents a structured & scalable approach to continuous product discovery which will enable you and your team to act.