Moving beyond the feature factory—building better, not just faster
Why focusing on user impact and sustainable practices trumps endless output in the long run.
Photo by Israel Andrade on Unsplash
We’ve all been there. The pressure to deliver, to ship, to do. It’s a familiar hum in the world of design and development. But in the rush, it’s easy to fall into a few common traps that ultimately hinder our progress and the quality of what we create.
It’s a topic I’ve explored before in a couple of previous articles, but I wanted to bring my thinking together in a single post to paint a clearer picture of how I view the topic and how we can work more effectively in the long run.
It’s a trap!
One of the biggest pitfalls is what is known as the “build trap.” We can get so caught up in the act of building, pushing to get something new to the market, that we forget to ask the fundamental question: Are we solving the right problem?
After all, it’s tempting to jump straight into solutions, addressing the perceived problem rather than digging deeper to understand the actual user need. Especially when you’ve a stakeholder breathing down your neck reminding you, “We’ve got a hard deadline that we can’t miss or push”, “We’re only releasing this feature to a small number of users so we can come back later and address the quality issues”, and the list of excuses goes on.
”In the Build Trap, the focus is on shipping features instead of solving customer problems. This leads to products that are overcomplicated, unused, or poorly received by users.”— Melissa Perri, Escaping the build trap
When we begin to prioritise output over outcome, measuring the number of designs produced and features shipped (output), valuing these higher than the benefits to internal and external users (outcome) we’ve started down a slippery slope that lead to a lot of wasted effort and be way more costly to correct in the long run. Martin Fowler explains this in more detail, and a lot better than I can within the tradable quality hypothesis, but if your focus shifts to output, then you should be asking: “Are we truly moving the needle and achieving a specific, valuable result, or are we just churning out features?”
Why do we value output over outcome?
We like to be able to put a number or value to something so it can be quantified, and of the two output is often the one that is more easily quantified and gives the most immediate results compared to outcome, which will often take days, if not weeks, before showing the results of our actions.
“We love intensity for the simple reason it’s easy to measure, …We like things that are fixed in time and easily measured.”- Simon Sinek lecture
Because of this, we often face resistance when championing a shift away from outputs, especially from executive teams and leadership if they’re used to counting success by the number of releases published, features pushed, and screens designed. These are not great metrics for showing the value teams are bringing to users.
When too much emphasis is placed upon these metrics, it leads to a focus on shipping, which causes corners to be cut, quality to be dropped, team morale to be lowered, and user-focused metrics like retention and activations to be harmed. Thus, we’ve ended up in the “build trap”.
How do we escape the build trap?
It’s usually at this point that comments around consistency and adding more bodies to teams will automatically solve the problem begin to surface. And while that might seem intuitive on the surface, it usually does more harm than good. Think about it: onboarding new team members, getting everyone aligned on the goals, and ensuring clear communication takes time and effort.
Now, that’s not to say it can’t work. It’s an investment, and while it can pay off in the long run, it’s crucial to acknowledge the initial dip in speed. However, this can also start a new problem, which is more work being funnelled into the team as they have more resources and more often than not, this puts you back to square one.
So, what do we do? Well, if we’re willing to invest in solving the problem, we should consider building habits of consistency. Create processes, elements, pages, and anything that can be reused. Like building any habit, it takes time at first, but the benefits will quickly follow.
Think of consistency as if you’re building a habit. It’s the accumulation of small habits that, when repeated consistently, compound to create significant results. It takes time, sure, but we need to concentrate on creating the processes and routines that lead to results rather than focusing solely on goals.
Ultimately, the goal isn’t just to produce more; it’s to produce better. It’s about understanding the problem we’re trying to solve, building a solid and consistent foundation, and focusing on the outcomes we want. By balancing the need for speed with the critical importance of quality and consistency and investing in systems that promote efficiency in the long run, we can build products delivered quickly, effectively, user-friendly, and built to last.
Try this…
You don’t have to overhaul your entire process in one foul swoop; it’s possible to do this in stages. And you can start as big or as small as you like. Here are three ways in which you can start making a change:
Build a culture of ownership.
Cultivating a genuine culture of ownership, where teams feel responsible for their features and have their contributions valued, makes a tangible difference. By empowering them to build something they own, rather than just executing a vision, you tap into their intrinsic motivation and trust in their professionalism to deliver quality work, provided clear expectations are set.
Build quality into your estimates.
Since your team cares about their work, allow them sufficient time to ensure its quality. This means including time for not just development and reviews, but also thorough testing and design evaluations. Prioritizing quality over arbitrary deadlines is essential; as Gabe Newell wisely put it, ‘Late is just for a little while. Suck is forever.’
Build a design system.
While the idea of a design system might seem daunting for a small startup, consider starting with a foundational set of consistently reused components. This doesn’t need to be a fully tokenized and rigid system, but rather a collection of core elements like inputs or modals that form the building blocks of your product. You don’t need to build everything from scratch; leveraging existing systems like Material or Tailwind can provide a valuable starting point that you can then adapt to your specific needs over time.
Here are my previous articles on this topic: Finding the balance: Speed vs Quality and Building Consistency: Why It Matters. Hopefully, I’ve refined the message a bit above now that I’ve had some time to reflect, but I’d love to hear your take on the topic. Share your experiences below, or if you want to continue the conversation, feel free to contact me here, on Substack or on LinkedIn.
Moving beyond the feature factory-building better, not just faster was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
