01 — Principle
Understand before building
Study the people, business, process, constraints and environment before defining a solution.
How I work
Start with the problem.
Technology comes later.
The work begins by understanding what is happening, who experiences it, what constraints exist, and what meaningful improvement actually looks like.
The process
11 stages.
Continuous loop vs linear completion
UnderstandBuildObserveLearnImprove
- 01
Understand
Understand the people, environment and situation.
- 02
Investigate
Question assumptions and find the underlying problem.
- 03
Map
Map workflows, relationships, dependencies and pain points.
- 04
Define
Turn the problem into a clear, achievable scope.
- 05
Design
Design the experience, system and solution around the actual need.
- 06
Validate
Test the thinking with users and stakeholders before going too far.
- 07
Build
Develop the system incrementally and deliberately.
- 08
Test
Test functionality, usability, security and real-world behavior.
- 09
Deploy
Put the solution into its operating environment and make it usable.
- 10
Observe
Watch how people actually use it—not how you expected them to.
- 11
Improve
Learn from usage, feedback and changing requirements.
Working principles
How decision making happens.
02 — Principle
Make scope clear
Define priorities, assumptions, exclusions, responsibilities and what success means.
03 — Principle
Build responsibly
Treat security, maintainability, ownership, documentation and operational cost as part of the system—not things to consider after development.
04 — Principle
Listen throughout
User engagement isn't a kickoff activity. It continues through design, development, delivery and improvement.
05 — Principle
Don't build what won't be used
A technically impressive system has little value if it doesn't fit the people and workflow it was created for. I would rather simplify a solution that people understand and use than build unnecessary complexity that looks impressive but solves the wrong problem.
Local reality
Technology should work where people actually live.
Connectivity, devices, cost, local payments, language, digital literacy and maintenance capacity are engineering inputs—not afterthoughts.
A solution that works perfectly in a controlled environment but fails because users have unreliable connectivity, limited devices or workflows that don't match reality isn't a successful solution.
"The environment is part of the engineering problem."
The purpose
The goal isn't technology, It's improvement.
A better workflow.
A clearer process.
Less manual work.
Better access.
Better information.
A new possibility that wasn't practical before.
Technology is the means. The improvement is the point.