Improve Your Startup’s Product Quotient

Startups are hard. Everyone knows that, but as entrepreneurs we have the amazing ability to kid ourselves into believing that this time it will be different.

For early stage startups, one of the most important things (some would argue the only thing that matters) is achieving product-market fit. Much has been written about PMF: what it is — and isn’t; how to recognize it or measure it (“you’ll just know”); and many definitive guides for how to get there.

However, a lot of these so-called guides are by necessity articulated in terms of generalities: pick the right market, hire the right people, at the right time, and they will do great things. Sounds like a plan, right?

Well, reality is a bit messier than that. Real teams include people from many walks of life, with a mix of experiences and skills. Sometimes, teams work together effectively to achieve something great. Sadly, more often than we would like to admit, that alchemy doesn’t happen and results are lackluster.

As a founder and product management leader, I’ve had the chance to work with, hire and/or lead a large number of engineers, product managers, designers, marketers, data scientists and other roles. Each person brought great perspectives and skills, but having all of them work together as part of a larger whole towards a shared target has not always been easier.

Over time, I’ve realized that we need a common framework, or at least a shared mental model, to help us all get pointed in the right direction. It’s not about following a strict process, adopting a particular organizational structure or following the business-guru-du-jour’s 7-step process.

The truth is that there are no shortcuts. On the other hand, if you can equip your team with some basic tools that work across all roles, that will increase the chances that they will communicate effectively and play well together.

For a product-focused team, what they need is shared product smarts. I call this the Product Quotient™. You’re already familiar with the Intelligence Quotient (IQ), which is a measure of a person’s reasoning ability, and the Emotional Quotient (EQ), which measures a person’s ability to understand other people, what motivates them and how to work cooperatively with them.

The Product Quotient (PQ) is a team’s ability to reason about their product, understand their customers, align on a common motivation and work collaboratively towards a shared set of product objectives and outcomes.

Let me break this down a bit.

• The first difference is that the focus is on team vs. individual ability. This matters because all meaningful products are the result of a team effort. Too often companies use the term “the product team” in a narrow sense to refer to only a smaller group of people typically with the title of product manager. Instead, the product team should extend to everyone working on the product or perhaps on solving a particular set of customer problems.
• Reasoning about the product means considering — together, as a team — all aspects of the product, from what need it’s trying to address to how it should be communicated to potential adopters. Especially in larger companies, where role specialization (and, let’s face it, organizational fiefdoms) distribute tasks across different departments, the work on different aspects of the product can become a sequential production line. Instead, by elevating the collective PQ of the team, every member can contribute and also integrate elements into their view of the product.
• A product’s purpose is to delight, meet customer needs and ultimately to create value for those customers. This requires a deep understanding of each customer. While some people on the team may have specific skills, e.g. a user experience researcher may be able to conduct great interviews, it’s best when everyone on the team has a deep, first-hand understanding of the customers they are serving. Some engineers may initially be reluctant to engage directly with customers and may prefer to stay within the comfort zone of their development environment, but overcoming this hesitation often results in keen insights that help raise the team’s PQ.
• When a product team comes together around a clear objective and shares a common motivation, their chances of success go up dramatically. There’s plenty of literature on different approaches for objective setting and measurement, such as OKRs. From the point of view of improving Product Quotient, what matters most is that the team develop their own set of objectives through a joint process. This results in a shared sense of ownership that helps the team transcend their individual roles.

At my current company, InOrbit, we are on our journey towards becoming product-centric. As part of our efforts around raising our Product Quotient, we always try to have engineering, UX design and product management participating in defining scope and setting objectives. We meet regularly as a company to work on overall product priorities; anyone can chime in with their own ideas. Instead of having a fixed organization, we have epic teams that come together fluidly to work on the ebb and flow of product initiatives. Everyone on the team (including engineers, of course) is encouraged to talk to customers directly, whether as part of discovery before launching a new epic, to demo some work-in-progress concepts or to gather feedback from customers who join our early access program.

We’ve adopted some small social-engineering hacks that help keep everyone pushing in the right direction. For instance, whenever somebody uses “product team” narrowly to define to the product managers, somebody else (initially just me, but more recently others, too) will say “we’re all product”. Likewise, I’m adamant about not using the term “resources” to refer to people (most frequently, engineers) and will often correct the use even if mentioned in a casual conversation. While this is a fairly common use of the word, it reinforces the wrong idea: that engineers are just a means of production that will be deployed during implementation, rather than integral members of the product team who self-direct and actively participate in defining objetives. Old habits die hard, but we’re making progress and this has become a meme.

That’s not to say that we always get it right. For instance, for a recent epic in which we wanted to support integrations with external incident management systems, we assumed it would be mostly API work and initially did not loop in a UX designer. Then once the team started digging deeper, we discovered that there were several changes we wanted to introduce that would impact our existing UX in order to align the API with the in-app experience. This was a miss, but we were able to recover quickly because the UX designer already had a ton of context about other aspects of our product and our overall vision.

If you’re currently immersed in running your company as a company founder, I’d love to hear how you’re helping increase your company’s PQ. If you are sitting on the sidelines waiting for the right time to start your own company or licking your wounds from a former startup at a cushy corporate job, then once you launch try this out to make sure next time it really is different.