Ask questions like a Product Manager

“Product” is not a profession. It is a set of responsibilities that no company can opt out of. Being a “fullstack dev” includes taking on some of these product responsibilities. Here’s the good news — it’s totally achievable. And if you start thinking like a PM, it will work wonders for your product, your career, and your company culture.

Product management starts with great questions.

Before becoming a PM, I joined a company with no PM and no established product processes. Here are the types of conversations I had when I first talked to the engineering team:

What are the priorities here?

We work on whatever the CEO is most focused on this week.

Why are you doing what you’re doing today? Is your current project aligned with the company's goals?

Not sure. Our team doesn’t set goals, or measure progress toward goals. That’s not something we’re responsible for – we do as we’re told.

What are the other engineers on your team working on right now?

That’s not my business.

Who makes design decisions?

We don’t really do that here. Engineers just decide as they go.

What are the main problems our customers have? Does this project actually solve a problem?

You’d have to ask our sales guy — he’s the one who talks to customers. It feels like he promises features that we haven’t built yet. We don’t talk much — I resent him and our customers.

How do you know the code you’re writing today works well with the code your colleagues are writing?

We usually just start working, and find problems as they arise.

The team had opted out of their product responsibilities. It's as if they had said, “Oh we just don’t have hygiene here. It’s not one of our concerns.” If we think we don’t have hygiene responsibilities, we stink and we don’t know it.

So what are product responsibilities? Consider what a PM does at a software company:

• Articulate the vision and a prioritized roadmap
• Gather insights from customers and other market data
• Curate a list of customer problems
• Propose solutions to customer problems via robustly scoped projects
• Organize the implementation of solutions via tickets and sprints

We had priorities, but they were chaotic instead of strategic. We received insights from customers, but our devs didn’t know about them. Our founders had a vision, but it was not clearly articulated to the team. We designed features, but on an ad hoc basis using people who aren’t designers. We clarified engineering tasks, but only after accruing tech debt and massive merge conflicts.

Even with a PM, the absolute best case scenario would be that everyone thinks and asks questions like a PM. An excellent fullstack dev should be able to answer these questions. Maybe no one in your organization is asking you hard product questions. If so, it's up to you to ask them! Here is a list of questions that every dev should be able to answer:

• What are the company goals?
• What am I doing to help achieve these goals?
• What are we working on right now, and why?
• What are the next 3 projects we’re doing after this? Why?
• How many different projects are in development right now? What are they, and who owns them?

• What is the main problem that our product solves?
• What are the top 3 complaints from customers right now?
• Who are our largest customers and what do they want that we haven’t built yet?
• Can I name 5 actual humans who use our product?

• Is the ticket I’m working on crystal clear? If not, who can clarify it?
• What is the estimation of the ticket I’m currently working on? Did anyone else weigh in on that estimation?
• If I have a design question, who should I reach out to?
• Is my current project as small and simple as possible? Does this project introduce tech debt, complexity, or unnecessary surface area?
• Are any of my colleagues blocked today? Am I able to help them?

If you can answer these questions, you're able to make great decisions and contribute efficiently. You can challenge bad ideas on the grounds of “this doesn’t align with the company goals.” And there will be a direct line between what customers need, and what you are building day to day.

If you cannot answer these questions for yourself, start asking them out loud to other people, and don't stop until you get good answers.