Stop Building What You Think Users Want—Start Building What They Need

A great Monday morning to you,

Let me share a story that might sound all too familiar: A team of yours worked tirelessly to deliver a project on time, within scope, and on budget—only to find out that no one actually used the software.

Several Reasons led to that problem:

• We conceptualized and planned the project in our own headquarter world

• Our only negotiation between business & IT was based on scope-time-budget - how much ‘we’ as IT were able to deliver in the least amount of time and yeah… maybe budget

• The solution was completely oversized including features no-one really needed

Maybe one fun fact: The customer front-end was remarkably beautiful … especially for Management to have on their Power Point Slides. The actual user was having trouble finding what he or she needed.

Because it didn’t solve the real problem the users had, we had to dig in a little further,

What did we do?

1. Get out of the building and speak to the users: Such a simple idea and yet I have hardly experienced anyone actually doing it. We talked to the real people who had to use the software. Suddenly, people showed up that we had never considered e.g. Backoffice Operations (people whose job it is to key in e.g. customer data into 2-3 different legacy systems)

   Therefore, ask a person out on the street, on the shopfloor, maybe even talk to your mom. Avoid talking to a representative of a group of people. Feedback is often striking and simple. By observing how people interacted with our product, what questions they asked and which thoughts they had we were able to deliver solutions that actually made lives easier, not harder. And yes, we talk about business applications that you have to use at work, daily.

2. Iterate Based on Feedback: We used (also harsh) customer feedback to inform our next steps and nailed down the issue we wanted to solve. Especially with custom build software you have the amazing freedom to deliver something of true value if you get it right. At this moment you have two option: Be fearless and adjust your approach because you discovered your assumptions were wrong. OR force down an application to the user through ‘policy’ and ‘management instruction’ (Probably happens in more than 90% of the cases, believe me)

3. Measure Real Success: Once we (as a team) agreed on which single value we wanted to improve, it became quite obvious what topics created impact, and which weren’t. Instead of celebrating that your project was “on time and on budget,” ask yourself if it’s actually being used and making a difference. I have been in countless Steering Committees and Project Meetings were usage was low due to exactly the reason being the software does not meet the actual problem that needs to be solved.

Remember, the goal isn’t just to build features—it’s to deliver real value.

Take a moment to reflect & sit back, and ask yourself whom you might want to talk to

Yours,

Sophie

P.S This Newsletter has been written by a human being - forward it to anyone you might think enjoys a read like this. I guess AI wont f* it up as much as I did.