How I Work
My process depends on the situation.
Working inside a large organization is different from helping an entrepreneur shape a new business, or supporting an internal startup inside a bigger company. The people, constraints, politics, speed, and risks are different.
I was trained in user-centered design and use it extensively in my work. Depending on the situation, I may follow a full research and validation process, a lightweight version of it, or techniques borrowed from frameworks such as Google Design Sprint.
Rather than following one rigid methodology, I adapt the process to fit the problem, the team, and the level of uncertainty involved.
Validate early, but carefully
I believe in testing ideas early with customers or potential customers.
But customer research has to be done carefully. The wrong questions, asked too early or in the wrong way, can kill a strong idea or push the team in the wrong direction.
There is an art to knowing when to involve customers, what to ask, and how to interpret what they say.
Don’t “fix” what is working
I don’t redesign things just because they look old, inconvenient, or tempting to improve.
If something is working, I leave it alone unless there is strong evidence that it is causing problems.
Change should earn its place.
Manage around people’s strengths
As a manager, I look for the one thing each person does unusually well, enjoys doing, and can keep getting better at.
Then I try to shape the work so they get more of that.
That is usually where the best work comes from.
Pay attention to patterns
Good ideas rarely appear out of nowhere.
They often come from noticing repeated user problems, shifts in technology, and patterns in adjacent industries.
I try to stay attentive to those signals and connect them before they become obvious.
For example, the idea of building apps through natural language came from seeing several things come together: low-code tools were becoming too complex, language interfaces were improving, and in user studies, when asked how they would design the tool from scratch, several users said some version of, “I would just write what I want.”
Innovation often starts with noticing the pattern early.
Use the system before adding a new one
Inside organizations, I try to work with the existing mechanics first.
If there is already a process, structure, language, meeting, tool, or decision path that can do the job, I use it before creating something new.
In general, I don’t multiply entities unless necessary. That applies to design, process, management, and honestly, life.