Built Exactly as Asked, and Still Unused: Why Software Misses the People It's For

We built exactly what the client asked for. When they tried to sell it, nobody wanted it.

Earlier in my career, we were building a mobile app to help new graduates adjust to their first jobs.

We didn’t fully recognize the problem until launch. The companies that would have bought the product showed no interest. I’m not sure the app ever reached the employees it was meant to help.

Dead on arrival.

We had brought instructional design expertise to the project, and the individual exercises were relevant. But they never added up to a meaningful whole. I think the experience failed to show learners why they were completing each exercise or what it was supposed to help them accomplish. Maybe it was a little too cute and a little too gamified, and the real value got lost.

The team had delivered the client’s vision. That vision had never been validated.

The idea came from leaders who knew their market and were confident in it, and that confidence was reasonable. We suggested more research, and the decision was to build first. Ultimately, without validation and proof of improving new hire orientation, our client’s buyers were never going to take a risk with such a new and unproven approach.

If you run a nonprofit, the companies in this story are your funders and the employees are your participants. You can satisfy one group and still miss the other.

A vision is a set of assumptions. Testing them doesn’t second-guess the leader. It protects the vision from finding out too late.

This is one way custom software projects fail. Faithfully delivering a request does not help when that request is disconnected from what end users value. Successful software development requires two things: a clearly defined audience need and regular validation that what’s being built addresses that need.

So ask a better question: How do I make sure what gets launched is what my end users need?

Define success, then put it in front of users

In Fabrik Labs kickoffs, we often ask clients to complete one sentence:

We’ll know we’ve been successful if…

We may also imagine newspaper or trade-magazine headlines written a few years in the future, along with quotes from people describing the organization’s success. Then we work backward: What would have to happen between now and then for those statements to be true?

These exercises uncover what the organization is trying to accomplish beyond a feature list. We use that purpose to establish a north star with measurable indicators. That north star becomes the anchor for your product roadmap.

The onboarding product did not have one. Looking back, a useful north star might have been:

Our goal is to help new employees orient to the world of professional work after spending the past 12 years as professional students. We’ll know we’ve been effective when users of our app can list the ways that the workplace differs from academia and the skills they’ll need to build to be successful.

Now there is something to test.

Talk to end users with a short discussion guide. If the idea is difficult to convey in a conversation, build a basic prototype or mockup and get feedback on it. A week or two spent testing the largest unknowns in the plan can keep you from learning after launch that the original vision was wrong.

We had another project where the vision was a super-clean search-driven interface. Medical professionals would easily search for answers within previously hard-to-access scientific documents.

When we tested this, users struggled with understanding what to ask. We realized we had to provide some indicators of what existed behind search. Future iterations surfaced the products it covered and categories of content, helping users orient to what they might ask. With this feedback, we launched a system that continues to be used many years later.

Test the riskiest work while it can still change

Your team should be putting their work in front of real users throughout the build, not just at the end.

The product does not have to be fully functional. Explain what is unfinished, then show the parts that are working. Use the session to address the questions that remain. These can be very lean sessions with just 2–3 end users. You’re trying to uncover early signals of the big barriers to use, not granular feedback and fine-grained tweaks. If they’re there, they’ll be obvious to your audience even if they aren’t to your team. This doesn’t replace more holistic product testing, but it does help to avoid major blind spots along the way.

There is one catch: ask your team to schedule the riskiest parts first, while those parts can still change. Once the team is too far down the line, changes become harder and costlier to make.

What to look for in a partner

In my experience, the most vulnerable point is the handoff from design to development.

Before custom software development begins, there is still room to ask questions and push on assumptions. Once the product starts being built, people tend to focus on what it does instead of the user outcome it is supposed to create.

Your developers should be part of the design process from the beginning. They’ll hear the conversations and reasoning that drive the design before they begin building it.

You should have a strategist or product lead engaged from the start who remains involved during development. They preserve the project’s purpose and help the team check completed work against the north star at the end of each sprint.

Client leaders are most useful at kickoff and key milestones, including sprint reviews (but not day-to-day). They help set the vision and evaluate progress toward it. When the team learns something new, they help adjust the direction. The people guiding the daily work make the tactical decisions.

Most of all, look for a partner who will test your vision, not just build it.

Wrapping it up

A product that matches your vision isn’t a success yet. It also has to meet the needs of the people who’ll use it, and sometimes more than one group of them. Defining success for your audiences and testing alignment with those criteria throughout development is a critical step to achieving a successful launch.

If you have a vision you’re confident in, that’s a good place to start. If you’d like help testing it with the people it’s for before anyone builds, that’s what our Roadmap Workshop is for.