Building software is complex. Engineers juggle performance, experience, security, maintainability, testability and observability (that is a lot of balls in the air). With so many competing concerns, it’s easy to lose the forest for the trees and forget the most important reason we build software: to make an impact.

That impact might be helping a human directly, powering another service, or enabling another team. Whatever the case, the result should be an improved experience for someone.

Why are we building this?

Too often, engineers get so focused on the what that they lose sight of the why. On my teams, I put deliberate emphasis on ensuring every engineer understands the purpose of the work—and feels empowered to question it.

Asking “How will this create the intended impact?” keeps the focus where it belongs and helps the team search for the elusive pit of success.

Before starting a sprint or building a feature, every engineer must be able to explain why the change matters and what impact it will have. They should be able to paint a narrative for how the user’s experience will change and why that matters. And ideally tie this back to concrete metrics we expect to improve.

If the why doesn’t resonate with the team, it won’t resonate with customers either. That’s a signal to rethink or reframe the work. If I can’t articulate the why, I must question if I am propsing the right direction for the team.

Once the purpose is clear, engineers can (and should) continually ask during development: “Will this still achieve our goal?” Scope evolves and requirements change while building, and if halfway through someone realizes the feature won’t deliver the intended impact, that’s the perfect time to pause and reassess. It’s far cheaper to adapt or cut work in progress than to ship something that misses the mark.

In search of the pit of success

Clarity around the intended impact is the foundation for a culture that actively searches for the pit of success: a state where the user naturally falls into the impactful behavior you want to drive. That sounds obvious, but it’s hard in practice because of a core tension in software: features vs. simplicity.

Many products try to deliver value by adding features, flexibility, and configuration. While that’s useful, it often prevents users from stumbling into success. If there’s no current pulling toward a meaningful outcome, users will walk away, even if your product is technically superior.

But when engineers, product managers, and designers are aligned on the why, they can work together to deliberately design for the pit of success. This isn’t just about slapping a CTA button on a page. It’s about simplifying the surface area (UI or API) so users aren’t distracted, confused, or pulled off track.

Closing

Building software isn’t about features or technical cleverness—it’s about creating impact. When teams keep the why at the center, they’re more likely to build experiences where users naturally succeed (and choose not to build experiences where they won’t). That’s the real goal: designing so the pit of success is the only place to land.