What Google Taught Us About Product Ownership
By Michael Martin
One of the strongest predictors of whether a software project succeeds or fails has nothing to do with the technology. It's the product owner.
We've seen it across every engagement we've run. A capable, engaged product owner who understands their users and can make decisions quickly will get better outcomes with an average team than a brilliant engineering team will get with a disengaged product owner. It's that asymmetric.
This is something we think about constantly at Digital2DNA, and it's why we invest heavily in coaching our clients into the product owner role. Not everyone walks in on day one knowing how to write user stories, prioritize a backlog, or run a weekly review. That's fine. What matters is vision, judgment, and willingness to be present. We teach the rest.
Recently, I sat down with Rob Gray - a former product and operations leader at Google who I worked with years ago when my team built a data integration platform for Google's cloud sales organization. Rob managed product owners at Google, hired them, and coached them. He's seen what works and what doesn't at a scale most of us will never touch.
The conversation was part of our Product Owner Support Group on LinkedIn, where we regularly bring in experienced product leaders to share what they've learned. Here's what stood out.
The thing Google cared about most wasn't technical skill
You'd think Google - one of the most technically demanding companies on the planet - would optimize for technical capability in their product hires. Rob says that's not what separated the best candidates.
What I always looked for first was whether someone really understood the end user - the person actually using the product. — Rob Gray, former Google product leader
He went further:
You can have very capable, highly technical people with strong portfolios, but if they build technology for the sake of technology and ignore the end user, you can end up with a flashy product that never gets adoption. — Rob Gray
This tracks with everything we see in our own work. The projects that go sideways almost always have the same root cause: someone built what they thought was needed instead of what the user actually needed. Technical excellence without user understanding is just expensive guessing.
Everyone has a customer - even on internal products
One of the most common things we hear from product owners on internal projects is "I don't really have a customer." Rob's response was blunt:
Everyone has a customer, even if they don't think they do. — Rob Gray
At Google, most of Rob's products were internal-facing. His team would define the customer with extreme specificity - not "salespeople" but "salespeople in a particular region who need to do a specific set of tasks." Then they'd spend significant time understanding what those people actually did in their workday, not just in the application, but in their entire workflow.
The risk with internal products is guessing what users need instead of actually asking them. Spending time with them - even just informal conversations - opens your eyes to what their real needs are. — Rob Gray
This is something we emphasize with every client who serves as a product owner on our engagements. Your users are real people with real workflows. If you haven't talked to them recently, you're guessing. And guessing is expensive.
The MVP that changed everything
Rob shared a story that perfectly illustrates what good product thinking looks like in practice.
In 2014, he'd moved into a new role at Google that wasn't well defined. During a team offsite, one of the big problems identified was that salespeople couldn't find the materials they needed. The portal was overloaded and search results were useless.
Rob volunteered to own the problem. He sat down with salespeople, asked what they actually used, and built a Google Site with ten links on it - literally just the top ten materials they needed.
We launched it almost as a joke. But it took off because it solved a real problem in a very simple way. That tiny MVP ended up reshaping my job. — Rob Gray
Small, clear solutions that solve real problems. Not a six-month requirements phase. Not a massive architecture. Ten links on a page. That's the mindset we try to instill in every product owner we work with: what's the smallest thing you can build that proves the concept and delivers value?
How to become a product owner when nobody's offering you the role
A lot of people want to move into product ownership but feel stuck because no one is giving them the opportunity. Rob's advice was to stop waiting.
What I've often done is create the role rather than wait for someone to hand it to me. Find a problem inside your company that affects a meaningful number of people and that could potentially be solved in a relatively short timeframe. Then just start building. — Rob Gray
He pointed out that you don't need a big team:
A product owner, a UX person, and an engineer can be enough to build a lot. — Rob Gray
The point isn't to ask for permission. It's to demonstrate capability by delivering something useful. Once people see the value, the role follows.
First usage, then satisfaction
Rob shared a principle from Google's approach to measuring product success that I think is underappreciated:
First you want usage. Then you work on satisfaction. — Rob Gray
If only a small number of people use your product, high satisfaction scores don't mean much. The first goal is adoption - getting people to actually use what you built. Once you have usage, you can start optimizing the experience.
This is relevant for any product owner prioritizing their backlog. If your product isn't being used yet, don't spend time polishing features. Spend time figuring out why people aren't showing up.
What this means for how we work
We don't just build software. We work alongside product owners - sometimes coaching them through their first engagement, sometimes challenging experienced ones to think differently about their users.
The principles Rob described - user-first thinking, small MVPs, tight feedback loops, defining what a product is not - are the same principles we operate on every day. Hearing a former Google product leader articulate them in his own words reinforces something we believe deeply: great product ownership is the multiplier that makes everything else work.
Rob put it simply when talking about how aspiring product owners should learn the craft:
Spend 30 minutes talking to someone who has actually done the job, struggled, failed, learned, and grown. That can teach you more than a polished course. — Rob Gray
That's the spirit behind our Product Owner Support Group and behind how we work with clients every day.
If you're a product owner looking for a team that takes this stuff as seriously as you do, or if you're an executive wondering why your current delivery isn't working, we should talk.
Rob Gray is a former product and operations leader at Google. He can be found at robgray.org and on LinkedIn at graymatter. This conversation was part of Digital2DNA's Product Owner Support Group on LinkedIn.