Collaboration & Process › Product Thinking

Product Thinking

Understanding the user problem behind the ticket.

Also known as: product mindset, thinking like a product engineer, product sense, outcome thinking, product-minded engineer

Product thinking is understanding the user problem and the business goal behind the ticket, not just the ticket’s instructions. Engineers with it build better solutions, spot problems earlier and suggest simpler ways to achieve the same result.

Problem before solution

A ticket often arrives as a solution: “Add an export-to-Excel button.” A product-minded engineer asks, “What are they trying to do?”

• Maybe finance needs last month’s numbers in a spreadsheet, so a scheduled report would serve them better.
• Maybe the real need is sharing data with a partner, which suggests an API.
• Or it’s the right answer. But now you know the why, and can make good decisions about the details.

Questions to ask

• Who is this for, and what’s their situation? (user empathy)
• What problem does it solve, and how will we know it worked? Which metric should move (business metrics, north star metric)?
• What do users do today without it?
• What’s the simplest version that tests the idea (MVP)?
• What happens at the edges: errors, empty data, huge data, permissions, mobile (edge cases)?
• What are we not doing, and why?
• What’s the cost, now and in maintenance, compared with the benefit (cost of delay, build vs buy)?

What it looks like in practice

• Talk to users or support, or read their feedback, when you can (user research). One conversation can change a design.
• Use the product you build (dogfooding).
• Propose alternatives: “This would take three weeks. What if we did X, which covers 80% of the need in three days?”
• Raise problems you notice: confusing flows, missing states, inconsistent behavior.
• Care about outcomes, not just shipping. A shipped feature nobody uses isn’t a success (feature adoption).
• Instrument what you build, so you can learn from usage (instrumentation).
• Work with product and design as partners, not as a spec-delivering service (working with product).

Balance

Product thinking isn’t second-guessing every request or overriding product managers. It’s bringing technical knowledge into product decisions (what’s cheap and what’s expensive, what’s risky) and product context into technical decisions. The goal is to build the right thing, not just to build the thing right.