Are business requirements and technical constraints drowning out user needs?

Are business requirements and technical constraints drowning out user needs?

Do you ever have difficulty engaging teams with user stories in a meaningful way? Perhaps product owners are under pressure to deliver efficiencies or development teams are struggling with technical constraints and somehow user needs just can't compete with these dominant day-to-day priorities?

So how do you win people over?

A well-researched piece of work followed by a readout may do the trick. That has certainly been one of my default strategies in the past. The problem is that if this doesn't hit the spot you've got to explain and explain and that's where it's likely to fall flat. You run the risk of vying for people's already limited attention when what you really want to do is compliment their work and enhance overall productivity.

Read on for tips on how to deepen engagement and alignment.

Reframe problem as a team activity and find synergy

Even if you are a guru of all things insightful (really?), that's not enough to engage people with problem solving. A human-centred approach offers another way of seeing the problem and measuring success. Try to position it as an additional dimension for another perspective, supported by meaningful success metrics.

For example, an organisation may have a goal to grow by 20% within 12 months. Depending on what you do or where you sit in the organisation you're likely to see the problem and solutions in different ways:

  • Sales want to increase sales
  • Tech want to exploit existing technologies
  • User Experience (UX) seek to uncover opportunities to increase usage and retention
  • And so on.

Business and technical constraints are still very relevant. Human-centred and/or User Centred Design (UCD) offer another perspective and along with enhanced metrics, can help stakeholders to understand what matters to users, why it matters and the impact of UX on business outcomes.

When you combine all of these (albeit simplified) perspectives together you're more likely to establish inter-dependent rather than competing problem-solving approaches. Go a step further and work with divergent stakeholders to uncover how UCD supports the contributing disciplines and you'll discover plenty of points of synergy.

Breakdown ambitious goals into smaller bite-size objectives

If 20% organic growth within 12 months is the end game you're hoping for then you need to figure out how you'll get there; you'll want clarity on what steps to take and indicators of success (or failure) so you know you're on track. Start by breaking down big ambitious goals into bit-size objectives.

Are business requirements and technical constraints drowning out user needs?

Team goal or destination

Are business requirements and technical constraints drowning out user needs?

Break down ambitious goals into smaller
steps to help you reach your destination.

Incremental goals may look something like this:

Identify unmet needs and quantify the opportunity

  • The product team may have ideas on opportunities, the role of Research is to pin-point unmet needs and quantify opportunities so that the team can identify areas for ongoing development.

Ideate solutions and validate the solution-fit

  • Once the team agree the user problems they want to prioritise, then they can ideate and begin to validate the solutions directly on users.

Develop a prototype and test on users

  • Once validated they're well positioned to develop prototypes for ongoing test and learn.
Are business requirements and technical constraints drowning out user needs?

Define Key (success) results at each step of the learning cycle

If an objective is where you want to be, then key results are the link between objectives and achievement - in short they tell you how you can achieve goals.

Introduce a test and learn cycle as illustrated here and work with the team to define a learning objective and key results throughout the critical decision path.

For each key investment decision:

  • Start with learning goals and the key results i.e. what success looks like
  • Design experiments that help you learn
  • Execute and observe - track outcomes against OKRs
  • Reflect and learn in teams and make informed decisions.

Building on the example above Objectives & Key Results (OKRs) key may look something like this:

First decision - what OKR can help the team pin-point the best opportunities for to focus on?

  • At least 60% of respondents must have a better solution than what is currently available in the market

Next decision - how will we know that our concept works for our users?

  • At least 70% of respondents say the proposed concept is a solution-fit
  • At least 70% of respondents say they would try this innovation and/or recommend to others

Next decision - how will be know if our users are able to achieve their goals?

  • At least 65% of test participants say they can successfully achieve task with the prototype.

As you progress through the learning cycle OKRs are granular and at each decision stage-gate you gather evidence that you are on the right path or that you need to pivot. Keep the test and learn cycle going until you are confident you insights that help you achieve your overall team goals.

Keep in mind you are bringing the team on a journey so all key particles need to be involved in defining what success looks like each step of the way. The more transparent and easy to understand the key results, the more engagement you'll have with learning and problem-solving.

Develop insights for action together

Well-articulated OKRs position the team well to work together on tracking outcomes, developing insights that results in insight-driven decisions. Like co-defining OKRs, it's also advisable to co-learn.

Make sure you clearly distinguish between a measurable outcomes, observable findings and subsequent interpretations.

  • Measurable outcomes are what you track against ORKs.
  • Observable findings should be observable 'fact' right across the team and are usually specific - he said, she said, he did and so on. Everyone on the team should be able to hear and see the same thing.
  • Interpretations are how we assign meaning and are based on our unique view of the world.

Interpretations are critical for rich insight development. Because they are based on our unique experiences of the world, our perceptions rather than reality, they won't be consistent across the group. That's okay. The important thing is to make a conscious distinction. Observations tend to converge while interpretations are likely to be diverge. Divergence enriches learning. Different perspectives will help reduce blind spots, define what's feasible and unlock potential.

Stay true to the principle of learning

Last but definitely not least.

The purpose of test and learn is to LEARN not validate assumptions so you need to hold the learning principle solid. When the results are not as expected people may resist the outcome. Learning can be painful, often associated with failure and may feel like rejection. It's naturally hard to let go, especially as the team get more emotionally engaged with solutions. If OKRs are meaningful to people at each stage then learning and staying focused on desired outcomes will be valued over outputs. This helps the team make the necessary decisions to continue, pivot or yes, even the difficult decisions of no-go.

How to successfully achieve goals is clearer and more importantly based on insight rather than bias. This is what you're aiming for.

Connect with me on LinkedIn
Follow me on Twitter