Build Software Around the Person Doing the Work

The part of building software that interests me most is figuring out what would actually make someone's work easier. There's usually more to that question than the first conversation reveals.

Someone asks for a feature. They explain what it should do. You can see how to build it. But before committing to that answer, I want to understand what they're trying to accomplish, where they get stuck, and what happens around that moment. Sometimes the request is exactly right. Sometimes there's a better opportunity a little further into the conversation.

I've spent more than a decade building software products, from startups through more mature companies. The lesson that has stayed with me is that the person using the product has very little reason to care how impressive it was to build. They have work to do. If the software helps, the effort behind it has a purpose.

That sounds obvious. It's surprisingly easy to lose sight of when you're excited about what technology can do.

Understand what you're asking someone to live with

A product team spends a lot of time looking at its own software. The person using it is trying to get through a day that includes other people, interruptions, deadlines, and responsibilities the product team may never see.

I want to understand that day before deciding what belongs on a screen.

What does someone need to know right now? What are they holding in their head while they look for it? If the task gets interrupted, can they pick it back up? When they're finished, is the work actually done, or have we left them with something to copy, reconcile, or explain elsewhere?

Those questions matter because it's possible to make one interaction look efficient while leaving the larger job difficult. A form can be quick to complete and still create more work for the next person. A report can contain every number someone requested and leave them unsure what to do next.

For me, empathy becomes useful when it changes a decision. Understanding that someone is busy should lead to something more specific than sympathy. It should influence how much we ask them to remember, how information is presented, and how much work we can reasonably remove.

Pay attention to the work between the tasks

One example from building AveoDent, our dental practice management software, came from hearing how the front desk books a family.

A parent calls to schedule visits for three kids. The person at the desk wants them in the same afternoon, ideally at the same time, so the parent makes one trip. Done one appointment at a time, that means booking one child, then hunting for an opening near it for the next, then doing it again, while the parent waits on the phone.

What caught my attention was the coordination work sitting between three bookings for the same trip. The team knew what needed to happen. Getting the schedule to show it was becoming a task of its own.

That's an opportunity I want to notice as a builder. People may describe the frustration without asking for a particular software feature. Understanding the problem gives us a chance to propose something they didn't have to design themselves.

We built family scheduling. The front desk picks the family and checks which kids need a visit, and AveoDent finds chairs side by side at the same time. One tap books them all.

The side-by-side part matters because the real goal is the parent's trip, not three separate appointments. Showing the openings together lets the person at the desk offer one time instead of piecing it together.

Nobody juggles three searches while a parent waits, and nobody calls back to fix a booking that landed an hour apart. The family gets one visit, and the desk moves on to the next call.

For me, the interesting part is how the idea follows from listening. Once you understand where the work gets stuck, you can bring a possibility into the conversation that goes beyond making an existing screen faster. A small intervention can address a part of the day that people had accepted as something they simply had to manage.

Listening carries a responsibility to think

Taking people's experience seriously doesn't mean treating every suggested solution as a finished specification.

Sometimes someone knows exactly what they need. There's no reason to complicate that. Other times, they can describe the frustration clearly but have never seen a different way to do the work. Part of my job is to bring possibilities into the conversation that they shouldn't have to discover themselves.

That also creates a responsibility to stay open. Knowing what software can do doesn't mean knowing someone's work better than they do.

I want the conversation to go both ways: here's what I understand you're trying to accomplish; here's an approach that might help; what am I missing? A good idea can come from either side. So can the detail that shows why an apparently good idea won't work.

This is where I think product judgment matters most. Building everything people ask for can leave them with a collection of individually reasonable features that are difficult to use together. Someone has to think about the connections, make choices, and explain those choices in terms of the work they support.

The person who raised the problem should be able to recognize it in the answer.

Leave room to be wrong

Even after a thoughtful conversation, the first version is an interpretation. You learn something different when a person tries to use it.

They may hesitate where you expected the next step to be obvious. Something you considered secondary may turn out to be essential. A small change might make the whole process work better. Sometimes the underlying idea needs another look.

I see that as part of building the product. The process needs room for someone to say that an idea sounded right but doesn't quite help in practice.

That means keeping people involved beyond the initial request. Put something in front of them, listen again, and use what you learn. The responsibility doesn't end because the feature exists.

Meet people where they are

This is the principle I keep coming back to: meet the user where they are rather than telling them where they need to go.

It doesn't mean preserving every existing habit. Sometimes a better approach changes the work substantially. But you need to understand why someone does things the current way before deciding what should change. A step that looks unnecessary may be protecting against a problem you haven't understood yet.

The work is to bring your ability to build into contact with their knowledge of the job, and stay with that conversation long enough to make something useful.

That's what I want my judgment as a product builder measured against. Can someone accomplish what they came to do with less confusion, less repeated work, and fewer obstacles? The answer is found in their experience of using the software. It's worth listening closely enough to hear it.

If you want to see where this thinking ended up, the front office page shows family scheduling and the rest of the day, or you can book a demo and tell me what's getting in your way.