Hierarchy of Product Team Needs
I was on a run and thinking about Maslow’s hierarchy of needs and how a force ranked list of needs could apply to product teams. Here’s my attempt. Let’s walk through the levels:
Level one: talk with your customers daily.
You simply won’t have enough information to make good product decisions if you’re not talking with your customers every day. Call them. Email them. Ask them what they like, what they don’t like, what they wish your product could do, where they’re indifferent. Would they recommend your product to someone else? Who? Why not?
Level two: build and share prototypes.
You have customer feedback, and now it’s time to create solutions for their problems. A good product team should be able to quickly prototype (code, Figma, whatever) ideas that are Just Enough™ to demonstrate the value and begin to unearth usability issues. Prototypes should be lightweight and shareable with a single link.
Level three: implement lightweight metrics.
You’ve built some stuff and now it’s time to measure whether it worked. The metrics rabbit hole is rife with products and terms and general misdirection about what you truly need. Do a lot of reading, ignore most of it. A maturing product team does need some form of analytics and metrics to shore up what you’re hearing from customers—but you do not need to spend tens of thousands of dollars and two months integrating with one of the huge product analytics players right out of the gate. Not yet.
At this level, you only need to answer two questions: (a) what do we track to tell if our stuff is working and (b) how will we report on this data. For (a), basic things like page views, clicks, and lower level database fields can help indicate behavior (Have they turned on feature X? Set a date field with the date they turn it on.) For (b), you’ll either need to have direct access to the database and some SQL knowledge (it’s not hard to get the basics) or a web-based tool that simplifies the reporting for you. There are a lot of tools out there, just be extremely judicious about giving database access to a third party.
Level four: have a process for team self-improvement.
Ding. Welcome to level four. Enlightenment time. At this point, you should be completing enough create → ship → research cycles that recurring issues become apparent—especially if you’re looking at multiple product teams. Once you’ve identified these problem areas, you need to set aside time for growth and reflection. If you don’t, these small pains will become chronic injuries.
Companies that get stuck at this stage will hemorrhage good people. This is because good product people are used to improving through iteration, and they won’t hang around a company that doesn’t treat the team as its most important product. (Side note: your company is your most important product.) Self-improvement at this level can be as simple as design reviews, a book club, or team retrospectives. Just set aside time and do it.
Level five: refine delivery, release, and marketing ops.
This is the last one I could think of, and it’s all about making sure the people you’ve got doing the things on the bottom four levels are able to spend as much time there as possible. However, once you reach a certain size I think having a team or members of the team assisting in the delivery, release, and marketing of the things you ship can be a big time saver.
Regardless what you call it (product ops, project manager, etc.), it’s the acknowledgment that if you want product people talking to customers, creating prototypes, and looking at the data, then anything they do that aren’t those things is hurting the lower levels of the pyramid.
What’s not here?
A lot. I’m certain this isn’t one-size fits all. But in general, I think if you pour time into one of these levels without an equal or greater amount of effort going into the level below it, you’re setting yourself up for problems later on.