How to Set Up An Effective Product Discovery Team
One of my favorite films is the 1995 coming-of-age classic, Clueless. It’s a comedic goldmine. At one point, Cher, the protagonist, calls a social rival a “full-on Monet” to make her friend Tai feel less jealous of the competing classmate. When Tai asks what that means, Cher says, “from far away, it’s okay, but up close, it’s a big old mess.”
If you are building a new product in an enterprise setting, I have some news for you: your product is already a full-on Monet. The problem isn’t that it’s backed by untalented, uncreative, or incompetent people. In fact, it’s precisely your rockstar team that’s causing the problem.
How could creative, knowledgeable teams possibly impede your ability to innovate? People who excel in large companies, and the organizational structures that they comprise, are masters of complexity. This is especially true for people who develop enterprise-grade software. There is so much to think about when you are handling millions of users: nuanced edge cases, esoteric system integrations, forward and backward support, release strategies, cross-browser testing, CI/CD… the list goes on. There is so much to do that we create more and more specialized roles, such as “Senior Release Train Engineer, North America Video Products.” And the management and leadership to coordinate all of this is nothing short of remarkable.
But this incredible machine is not designed for innovation. Specialized people can provide valuable insight to new product development, but add too many to the team and you lose the forest for the trees. New product teams need smart generalists. And sometimes, the less they know going in, the better.
The difference between product discovery and product delivery
Product discovery teams are different from product delivery teams, but this distinction is not well-understood. Product delivery teams execute. They leverage know-how and best practices to build, sustain, and maximize on a known solution.
Product discovery teams, on the other hand, explore. They don’t pretend to know the solution. In fact, the good ones might question the very problem they set out to solve. One of the foundations of a strong product discovery team is a beginner’s mindset. It is what allows the team to stay open-minded, avoiding the usual patterns of thinking that generate the usual results.
When people are trained for product delivery, they struggle to perform in the discovery capacity. Yet this is what happens in most organizations. We fear outsiders and adopt a “not invented here” syndrome. We promote people who execute well in the current business paradigm, and let them lead the development of new products and services. Or we set up innovation labs and staff them with subject matter experts.
To innovate, keep your teams small, autonomous, and focused
As a services firm, optimizing our team for efficiency is critical. We need to be able to create value for clients of all sizes across all industries. We also need to be able to do things that our clients can’t do in-house or easily hire in. It’s a big challenge, and it’s driven endless iteration on whom we hire and how we set up our teams.
We’ve come to value intelligence, humility, skill, and curiosity. Everyone we hire are makers, and virtually everyone knows how to code. Over time, they gain a breadth of experience across industries which allows them to look at problems in abstract and long-sighted ways. These qualities make Philosophers extremely adaptable, without losing the beginner’s mindset.
When we staff our projects, we aim to have all of the expertise required for the project with as few people as possible. This helps ensure that the team is autonomous without diffusing responsibility too much. We’ve found that we can do almost anything discovery-related with just four core roles:
1. The Product Strategist
The product strategist’s goal is to uncover and champion the true needs of the users. This involves conducting user research, synthesizing it, and translating those needs into themes and features for the product. The methods used for this work are not industry-specific.
2. The Designer
If the product strategist is the project’s user advocate, the designer is its architect. He or she looks at the shape of solutions we want to try, crafting the form of the product to match its purpose. Our designers are masters at crafting digital experiences, without being limited to particular subjects.
3. The Engineer
Having a skilled engineer on the team throughout can be a good gut-check for technical feasibility, but can also be a surprising source for creative solutions. Creating functional prototypes or technical proofs of concept during product discovery can provide decision makers with a much more holistic understanding of whether or not to move forward with a product concept. Through our process, our engineers learn what they need to in order to understand the given domain, rather than making assumptions based on their prior experience.
4. The Product Owner
The final member on any InfoBeans innovation team is the product owner, someone who brings the client company’s interests into the mix. Where the other team members are concerned with desirability and feasibility, it’s this person’s responsibility to ensure that there is a viable business model that is strategically aligned with the company. This is the one person who has the domain experience, and can bring in other subject-matter experts as necessary.
If you’re looking for innovation, get out of the building
Traditionally, large organizations rely on acquisitions of innovative startups to continually grow their revenue or customer base. This model is broken for many reasons, but perhaps the worst part about it is that it prevents companies from building the capacity to innovate in-house. You may be able to buy an innovative product or business, but you can’t buy the ability to innovate. You have to build it in a way that works with your culture.
That said, changing the way you work is easier said than done. Many organizations have transformation initiatives around becoming leaner, more agile, and/or more design-oriented. But these efforts take many years of training and investment.
Whether you are amidst a transformation or not, consider partnering with firms that will continually bring in an outsider’s perspective. According to Steve Coley, Director Emeritus at McKinsey & Company, emerging businesses require a different set of performance metrics and organizational style than existing lines of business (link). Put simply: you won’t get new results by working in the same old ways.
Outside partners, whether they are technology startups or design firms like Philosophie, are a great way to infuse new ways of working. Thinking about problems in new ways, and applying new methods to solve them, can produce the breakthroughs you need when you’re looking for innovation.