Product engineering

Product engineering in practice: problem before feature, the smallest valuable version, UX as engineering work and the trade-offs behind good products.

A product engineer is a software engineer who is responsible for the outcome, not just the ticket. The code matters, but the question I keep coming back to is simpler: did this make the product better for the people using it? I've worked this way as a consultant shipping products from zero, in product teams working close to customers, and as the founder of Settio, where there is nobody else to hand the product decisions to.

What product engineering means in practice

Start from the problem, not the feature request. A request like "add an export button" usually hides a real need: sharing a result, backing up data, reporting to someone. Finding that need often leads to a smaller and better solution.
Define "done" before writing code. What does the user see? What does success look like a week after release? If nobody can answer, the work isn't ready yet.
Ship the smallest valuable version. A narrow feature that works end to end teaches more than a wide one that is half finished. I'd rather release something small, watch it and iterate.
Treat UX as engineering work. Empty states, loading states, errors, offline behaviour and accessibility are part of the feature, not polish for later.
Close the loop. After release I look at crash reports, analytics and direct feedback, and I talk to the people using the product. That's where the next priorities come from.

Trade-offs I make on purpose

Product engineering is mostly choosing what not to build yet.

Speed versus reversibility. Moving fast is fine when a decision is easy to undo (UI copy, a layout, a feature flag). Data models, public APIs and anything stored on users' devices deserve more care, because they are expensive to change later.
Build versus buy. Authentication, payments and analytics are rarely where a product wins. I keep custom engineering for the part that makes the product different.
Consistency versus local optimisation. One shared design system and one way of handling errors beat ten clever one-offs, especially in Flutter apps that target several platforms from one codebase.
Today's deadline versus next year's codebase. Shortcuts are allowed if they are written down and paid back. The ones nobody remembers are the ones that hurt.

Working with designers, product managers and customers

The best results I've seen come from short distances between the people who decide, design and build. In practice that means joining discovery conversations early, prototyping in real code when a static design can't answer a question, and explaining technical constraints in terms of user impact ("this takes three more seconds on a slow phone") instead of implementation details.