Tackling chronic short-termism

Or ways to stop the shift to feature factory.

Modern product teams are obsessed with getting results. It’s not a completely unjustifiable obsession. Results that are deliberately achieved can mean delivering value to customers, unlocking growth potential, addressing longstanding issues and a whole laundry list of high five-able things.

Another obsession that most teams share (or at least aspire to) is speed. Like results, speed is important. Purposeful speed can enable tighter feedback loops to learn faster, ensure quicker value delivery to the people using your product and inspire higher morale within a product team.

Results and speed aren’t at odds. They often complement each other when done intentionally. Continuous delivery can co-exist with big picture planning. However, when the pressure starts to mount and results need to happen thick and fast, shortcuts are encouraged and compromises start to trickle down.

Short-term results, long-term debt

How work actually works, is not something designers often spend too much time thinking about. That is until it starts inhibiting their ability to do work. Features and flows you’ve spent time researching, iterating and testing get descoped to death and inevitably ship half-baked and bug-ridden.

Trivial shiny objects take their place and get branded as low-hanging fruit so that a few (often vanity) metrics can look good on a dashboard. The next sprint becomes the bottomless dumping ground for problems that may impede reaching next quarter’s target goal. That long-term vision the team rallied around may start to look more like a fire fighting schedule.

On top of all of that, there’s no semblance of how that string of quick wins sitting in the backlog actually contributes to what was once a clear pathway to becoming a market leader.

That’s what chronic short-termism looks like.

Eventually, the quarterly stat-padding exercises come back to bite you in the form of fragmentation, leftover experiments and all sorts of product debt which takes a hit on user experience and the team’s ability to recover. There’s probably many well-intentioned designers, product managers, and engineers that have gone through these experiences and haven’t come out unscathed.

That’s not to say something can’t be done about this though.

Treating it like a design problem

As a product designer, you’re entrusted with planning, designing and crafting end-to-end experiences that meet people’s needs and business goals. Sometimes the needs you’re solving for are in high stake settings. Think healthcare. A short-term solution within an electronic health record interface for a patient treatment plan could result in a poor design decision, which down the line might literally cost someone’s life.

So what can product designers do when the scaffolding holding everything together to prevent that from happening starts showing cracks? It’s easy to be an armchair critic and put chronic short-termism down to general shortsightedness.

However, as holistic system thinkers and stewards of product and service experiences we are more than well-positioned to leverage our skillset and treat this like a design problem.

Here are a few things you can do to help you do just that.

Ask questions, learn why it’s happening

Foster the same kind of curiosity you have about the people using the product, for the business strategy and the units of work that support that strategy. There’s always going to be tactical work and short-term goals you need to reach. That being said, if those goals are laddering up to nothing, assuming a passive role without asking about what the aftermath of taking on a task looks like can lead to an unwanted path.

Approaching problems with productive inquisition instead of blindly torpedoing every single request can help mitigate impulsivity in decision making and introduce a bit more thoughtfulness. Here’s a few questions you can start asking during kickoffs or at different stages of a project.

• Is this a problem worth solving?
  Compared to the other problems gathering dust in the backlog, ask about how the problem stacks up in terms of severity, customer need, and business impact. Look for tangible evidence that offers a signal as to whether the team should spend time on this or not.
• How does this contribute to the long term strategy?
  Assuming there’s one in place, inquire about how each step you’re taking furthers progress towards the vision the company has defined. Find out how you can measure those steps and if there’s any kind of causality that you can map from the thing you’re working on to the desired outcome.
• What do we expect will happen once we release this?
  Start rallying the team around thinking about the consequences of doing something. Think about what might go well and what might not. The act of being intentionally considerate about what might happen might even go as far as dropping a project entirely, because it may conflict with what the company is trying to do.
• What do the counter metrics of doing this look like?
  Often times we draw up a set of metrics geared towards measuring how successful what we’re doing will pan out to be. Measure the inverse of that. It might sound a bit contrarian, but what happens if that one feature is doing too well? Does it cannibalize other things we’ve built? Start factoring in the ramifications of over-optimizing a metric, and introduce counter metrics.
• How are we going to follow this up?
  Software is never done. Shipping something is the beginning of a conversation with the people you’re serving and the market you operate in, not the end. Ask about how the team plans to continue iterating upon what’s been shipped, how to respond to changing conditions and whether there’s a recovery plan in place should something happen.

Don’t underestimate the significance of how a small nudge in the form of a simple question can challenge a team’s thinking and shift the mentality from mindless delivery to deliberate rollout.

Frame decision-making and concepts visually

An underrated skill that product designers tend to not leverage too often is the ability to map and visualize all the micro-decisions, concepts and thoughts that happen before, during and after building experiences.

Visual aids such as feedback loops, relationship diagrams, quadrant charts, and graphs can not only translate complexity but also pinpoint the long-term impacts of making a specific change. When done well these diagrams start to reflect the new realities once short-term decision making enters the fray.

Forge alliances and network

For a bottom-up approach to gain credibility, you need people on your side. Spend time with different stakeholders, executives and other cross-functional partners. Don’t just go straight into your tin foil hat theory arguing why that one project should have never been green-lit in the first place. Pick your battles.

Listen to what they have to say and understand their reasoning behind certain decisions. You might find there are other influential forces that you haven’t even considered which could, in turn, better inform your approach to work.

Uncover and pay down product debt

Even if it’s not necessarily within the scope of what you’re shipping, take the time to identify product and technical debt within the feature space you’re operating in. Carve out time if you can afford to, and partner with your engineering peers to find solutions for resolving that debt gradually, even if it means sacrificing polish.

When it comes to design debt, follow your design system or try looking for anomalies in your work when it comes to component usage or input modalities, and converge towards singular nonduplicative solutions. In other words, leave the campsite better than you found it.

Conduct practical visioning

Design visioning is a helpful exercise that can give a team latitude to produce artifacts such as prototypes, videos, and storyboards that can inform strategic direction or better articulate a vision. It can take you away from the day to day slog of sometimes insular problems and shift your focus to where the company is going next.

Before conducting one of these exercises with the rest of the product team though, you’ll need to be careful it doesn’t turn into an art gallery. Practical visioning exercises, while loose in constraints, are still evidence-based and focus on the experience, not just the far-out technological capabilities.

If done well, visioning exercises can become something product teams can validate their activities against and leaders plan a roadmap around. Whether it’s a skunkworks feature-focused exercise or a product-wide effort, visioning can help hone in on a target and enable teams to work backward to see how they can get there.

Continuously delivering at the same pace in which people’s needs evolve and market dynamics change will always be critical. However, quarter to quarter survival will guarantee a path to become irrelevant.

If product designers want to move beyond the mundane interface assembly role they’ve been delegated to, they need to channel the same aptitude they have for building experiences towards changing the culture. In doing so remember to assume good intent on everyone’s behalf. Everyone’s trying to do the right thing.