In harder products, the problem is rarely a lack of ideas. More often, no one has yet named clearly what is really blocking the decision, who owns what and what the cost of the trade-off actually is. That is usually where I start.
Decisions have a cost
Every decision has a cost. We can understand it upfront, or take on debt and later pay the interest through churn, overloaded operations or financial loss. A clear decision-making process, preceded by discovery, helps reduce that interest. Listening to users, understanding the business and knowing the technical nuances does not remove risk, but it lets us take it consciously.
The most common interest
- churn
- operational overload
- financial loss
How I Work
Principles I apply in transactional products, partner programmes and enterprise delivery.
Start with the real constraint
Before jumping to solutions, I try to understand what actually constrains the system: regulation, data quality, partner dependencies, technical debt, user behaviour, operational cost or unclear ownership.
Make dependencies visible before decisions
In complex products, the problem is often not a lack of ideas but hidden dependencies: legal, technical, operational, financial and partner-related. I use process maps, decision logs, documentation and clear ownership to help teams make better decisions.
Adapt discovery to real constraints
Discovery does not always happen in ideal conditions. When data or research access is limited, I combine workshops, user conversations, customer care feedback, technical constraints, legal/tax analysis and staged rollout decisions.
Own the outcome, but respect the craft
I set direction and help decisions happen, but I do not pretend to be the designer, engineer or lawyer. Good product work happens when people who know their craft have enough context to do their part well.
Use AI where it genuinely shortens the path
I use AI for documentation, synthesis, exploring options, understanding APIs and rapid prototyping. I do not treat it as magic, but as a tool whose output still needs to be checked.
What supports this way of working
My results reflect the same patterns that show up in how I work: arranging complex situations, solving problems at the root, gathering information before a decision and taking responsibility for outcomes.
Arranging complex situations
Bringing people, dependencies and resources together so chaos can turn into action.
ArrangerFinding the root of the problem
The symptom is not enough for me. I want to understand what actually drifted and what is worth fixing.
RestorativeInformation before the decision
I gather, organize and test the context before I assume I know what should be done.
InputLearnerResponsibility for outcomes
I care not only whether the task was completed, but whether the whole thing actually works.
ResponsibilityContext over control
With people, I prefer building clarity, feedback and autonomy over steering every move from above.
DeveloperIndividualization
Full CliftonStrengths profile: Arranger · Learner · Restorative · Individualization · Developer · Input · Achiever · Ideation · Futuristic · Responsibility