My background includes building digital products and hosting Building The Future.
Those are different activities, but the connection I bring into product work is simple: give the other person enough room to explain the situation before deciding what it means.
When a conversation starts with "We need an app," I want to understand the experience behind that request. Not to slow things down. To make sure the work is aimed at the right problem.
So I start with what happened, not with what should exist.
"Walk me through the last time this happened"
I prefer a concrete example to a general description.
"Approvals take too long" gives us a topic. "Last Thursday, a request sat in someone's inbox because nobody knew who could approve it" gives us something to examine.
Who submitted it? What information was available? Where did it get stuck? How was it eventually resolved?
The details help us tell a missing feature apart from unclear ownership, missing information or a process that software might not fix on its own.
"Who does the work, and who feels the consequences?"
The person buying a product is not always the person using it. I want to understand each role separately:
- Who enters information?
- Who makes the decision?
- Who needs visibility?
- Who maintains the system?
- Who has to repair the situation when something goes wrong?
A dashboard that satisfies management is not automatically a useful workspace for the person doing the underlying task. Both perspectives belong in the conversation.
"What do you use today?"
I want to see the spreadsheet, email template, paper form, shared document or existing application.
Not because the current solution is necessarily good. Because it contains decisions.
A color-coded column might mark an exception. A copied email might hold instructions that never made it into formal documentation. A manual workaround might reveal a requirement nobody mentioned.
Those artifacts give us specific things to question rather than assumptions to carry forward. Seeing the real files and the real work is the point of discovery calls and walk-throughs.
"What would make this not worth building?"
I want room for a negative answer.
Perhaps the process happens too rarely. Perhaps the data it needs is not available. Perhaps a smaller change to an existing tool would solve enough of the problem.
These are useful discoveries. A good conversation should make it easier to decide not to build something when the case is weak.
"What would be meaningfully better?"
"More efficient" is a starting point, not a complete answer.
Would better mean fewer handoffs? Faster decisions? Less duplicate entry? Clearer customer updates? Less uncertainty about who owns the next step?
I want a description specific enough to guide the design and to evaluate the result.
Then the features
The purpose of these questions is not to write a perfect specification before anything starts. It is to build a shared understanding of the problem, the people involved and the change we are trying to make.
Then the feature conversation has something solid to stand on, and each feature can be given a job in the workflow.
If you have a product idea and a feature list already, email me. These are the questions I would start with.