Note before starting:
For this article, the customers I am referring to are internal users and our colleagues, but the same thoughts work perfectly for external customers.

I recommend redesigning from a user perspective rather than a computation design team perspective.

This was the feedback I had been waiting for!
Why am I so excited about it? The industry demands more citizen developers—engineers and architects transitioning into development roles—but the industry doesn’t evolve accordingly. As a result, we continue building tools that are incomplete, poorly documented and fail to meet user needs.

It’s well known, especially in large companies, that new features or solutions are often launched only to end up half-baked, underdeveloped, or abandoned. In some cases, development teams follow a roadmap — that may not have even been defined by them — and they deliver everything on that roadmap by the end of the year. From a development perspective, they check all the boxes—they committed, and they delivered.

But did any of it move the needle for the business? Not really. Why? From a product leadership perspective, no one connected the work to the business outcomes they aimed to achieve, creating a huge disconnect. This is the danger of state-driven roadmaps. These roadmaps are often focused on ticking off features rather than aligning with evolving business goals or customer needs. The team sees success as delivering features rather than achieving business results. However, they end up with dissatisfied stakeholders because the business didn’t accomplish its objectives.

You are developing digital products

Big enterprises are like little economies, offering plenty of opportunities for developing internal tools and products. However, you will face the same challenges external solutions face when fitting into the market. You will make a mistake if you assume that internal tools don’t require the same rigour in user discovery, feedback loops, or understanding of friction points in usability and retention. Just because a tool has been developed for the business doesn’t guarantee it will be adopted!

I’ve often seen people get obsessed with launches. “I launched this, I launched that,” they’d say.
But I always needed to understand the excitement around launching something if nobody’s using it.

We must shift from focusing on features to impactful outcomes and from features to products, always keeping the customer in mind. What does it mean to put the customer first? This industry has a lot to learn from the digital world, and Amazon stands as a prime example of a company that places the customer at the core of everything it does.

Learning from Amazon

Define the goal and only then consider the course of action to achieve it. As Steve Jobs said at Apple’s Worldwide Developers Conference in 1997,

You’ve got to start with the customer experience and work backwards to the technology. You can’t start with the technology and try to figure out where you’re going to try to sell it.

From Amazon working backwards, you learn how Amazon is obsessed with its customers and their needs. Everything Amazon does is designed to meet the needs of its customers and make them happy.

Amazon follows a work backwards approach, starting by writing a press release for a product or service that doesn’t yet exist. From there, they work backward to design and build the product or service based on the customer needs outlined in the press release.

In our industry, much can still be streamlined, particularly from observing how teams deliver repeatedly. We have countless opportunities to start with inefficient processes and work backwards to understand how they can be improved from a user perspective.

If you’re thinking without writing, you only think you’re thinking.
by Leslie Lamport

Amazon even forbids the use of PowerPoint for planning. Instead, they rely on written documents, which everyone reads and then debates. Writing clarifies the ambiguous, reveals the gaps in logic, and uncovers assumptions that might otherwise go unchallenged.
The writer gathers feedback, reviews it, and incorporates it. This process unfolds iteratively, over and over again. Each proposal is tested through multiple iterations, where people are encouraged to speak freely, and decision-makers genuinely listen. If this condition isn’t met, the process fails.

I can tell you that working backwards is demanding because it feels unnatural. You’ll spend hours writing these documents when you want to move quickly, focusing on what’s right in front of you—especially when you’re excited about a cool idea or deep in the design process. Still, the defined goal can get lost in these moments, and projects run into trouble.
By elaborating on the goal clearly and explicitly and carefully considering the necessary actions to achieve it, this iterative process helps reveal the right steps before starting. This allows you to plan efficiently and take meaningful actions toward the final result.

Empathy is your weapon

I’ve made the same mistake and still see it repeated often: thinking we know exactly what needs to be done simply because we have an architectural or engineering background or have worked in project delivery. This doesn’t automatically mean we know what the customer truly wants.
Too often, we mistakenly introduce our personal preferences into the product because we feel confident in our decisions. However, this can lead to subpar outcomes.
The trap works like this: the more confident we think we understand the users, the less likely we are to test our assumptions. We start thinking, “I used to be one of them!” this leads to cognitive bias, making us believe we have the correct answer. According to Daniel Kahneman, it’s precisely when things seem obvious that we must question them the most. When you’re most sure, when everything feels certain and coherent, that’s when you’re likely to be wrong.

Developers thought that their users would be as tech-savvy as they were. But if you can understand not just “what I would do in that situation” but also how that person actually thinks and feels, even if it’s really different from your perspective, it gives you a great place to start bridging gaps, even if you disagree with them.
Empathy helps you build trust, which is a key factor in driving change. Engineers want to understand how things work and are happy to discuss solutions. Still, when presented with a solution that could solve their trouble, they tend to put it aside due to a lack of involvement or understanding. If people aren’t aware of new methods or don’t feel involved in the process, they are far more likely to reject them. To overcome this, building trust between technical teams and non-technical staff is essential. Bridging the gap between tech and delivery is the first relationship you need to work on. You can do this by creating informal networks between developers, your non-technical staff, and your customers.

Conclusion

No matter what tools or processes you implement, if the culture doesn’t support them, people will find ways to work outside of those solutions. Creating the right environment is essential to introduce changes in this industry.

  • Build trust and foster empathy: Create a genuine connection and build trust with your internal customers. Understanding the real needs of your users and making them part of the development journey are the foundations for a successful development process.
  • Adopt a work backwards approach: Start from the end, focusing on friction points. As both Amazon and Airbus have shown, innovation comes from removing obstacles that slow users down. Then, move backward to identify the required technologies and processes.
    Airbus has heavily invested in data homogenisation and harmonising processes. Doing so eliminated inconsistencies that slow down operations and create bottlenecks.
  • Commit to long-term growth: Every beta version or proof of concept is exciting and relatively easy to achieve. However,

    building software is way more than that. It’s like tending a garden, so whatever you take on, you have to commit to growing, tending, improving, and pruning for years until it really works.
    by Amar Hanspal.

    At Slack, they believe you need to invest enough in a feature to reach the point where that work starts to produce a significant change in behaviour or utility for the customer. You only stop when you get a point of diminishing returns.

Lastly, align your team around shared principles and beliefs to maintain consistency in building and delivering products. Here are some principles from Steve Jobs and Noah Weiss to help guide this approach:

Steve Jobs

  • Clarity and focus: A single idea, clearly expressed, can take you far.
  • Simplify the customer experience: More choices often lead to more confusion for customers. Always strive to do the work for them.
  • Refine to the core: Cut the product down to its essence.

Noah Weiss

  • Stay curious: Encourage teams to share their experiences and lessons from different domains.
  • The utility curve: Consider how each new feature or product will impact the customer experience over time, and be prepared to pivot as necessary.
  • Adapt to customer needs: Constantly reevaluate the customer base and their needs. At each growth stage, ensure that you’re preserving what worked early on while adapting to new challenges.

A huge thank you to Amar and Sol for their invaluable support.