Everyone asks questions like a product manager.

At Thunk, we are not merely devs for hire. We have our own product managers, and every project has one. But we also have a deeply held belief that a project is more likely to succeed when everyone on it asks questions like a product manager — designers, developers, junior engineers, senior engineers, all of us.

Here's the thing. "Product" is not a profession. It's a set of responsibilities that no company can opt out of. Being a good fullstack dev already includes taking on some of them, whether you've noticed it or not. The good news is that thinking like a PM is totally achievable — and once you start, it works wonders for your product, your career, and your team's culture. Product management starts with great questions.

What product neglect looks like

Before I became a PM, I joined a company with no PM and no established product process. The conversations with the engineering team went something like this:

"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?" Not sure — our team doesn't set goals or measure progress, that's not really our responsibility. "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?" You'd have to ask the sales guy. He promises features we haven't built. I resent him and our customers.

The team had opted out of their product responsibilities entirely. It was like saying, "oh, we just don't have hygiene here, it's not one of our concerns." And, predictably, they stank — and they didn't know it. They had priorities, but the priorities were chaotic instead of strategic. They had customer insights, but the devs didn't hear about them. The founders had a vision, but it was never clearly articulated to the people building the thing.

The questions every teammate should be able to answer

Even when a project has a great PM, the best-case scenario is still that everyone on the project thinks and asks questions like one. Maybe nobody is asking you hard product questions right now. If so, it's up to you to ask them yourself. Here's the list we hold ourselves to:

• What are the company's goals, and what am I doing today to help achieve them?
• What are we working on right now, and why? What are the next three projects after this one?
• How many projects are in flight right now, and who owns each of them?
• What is the main problem our product solves?
• What are the top three customer complaints this week?
• Who are our biggest customers, and what do they want that we haven't built yet?
• Can I name five actual humans who use our product?
• Is the ticket I'm working on crystal clear? If not, who can clarify it?
• Is this project as small and simple as it can be? Am I introducing tech debt, complexity, or unnecessary surface area?
• Are any of my colleagues blocked today? Can I help?

If you can answer these, you're able to make great decisions and contribute efficiently. You can push back on bad ideas on the grounds of "this doesn't align with the company goals." And there's a direct line between what customers actually need and what you're building today. If you can't answer them, start asking the questions out loud to the people around you, and don't stop until you get good answers. The questions themselves are half the work.