Speed Is Not The Metric Of Success

If time is a premium for you and you don't have time to read this and would prefer a video or podcast version please click on the links.

Contrary to frighteningly popular opinion, Speed is not the metric of success, though many managers and project leads still use it as the yard stick by which successful delivery is measured. Its worth mentioning at this point that 'speed' is a surrogate metric that translates to time and cost, but for the purposes of this article I will conflate them as 'speed'.

Not a single successful solution ever started with the question "What's the quickest solution I can create?" (though that is often exactly the question asked). Time is a limitation that we often have to factor in, but Speed is not the answer to it. The vast majority of projects are delivered late, go over budget or end up abandoned because of this one mistaken metric.

The problem is that :

Speed is a good metric for successfully delivering a project.

But Speed is a disastrous metric for delivering a successful project.

Don't build what's quick, build what's necessary! How do you judge necessary? You don't! Your users do. It doesn't have to be necessary to you, it has to be necessary to your users! That's where value and strategy should meet.

What's necessary to employees are a job and money. The people that make those happen are your users. They make that happen by wanting what you sell. It really is that simple when you look straight at it.

It is, quite frankly, terrifying how often I have to remind stakeholders, POs and delivery teams of this one important (and you'd think obvious) fact. But in the cut and thrust of delivering value for the team or project, they forget that they are subsequently not delivering value for the customer (and though they are outdated and poorly used, artefacts like Personas were originally invented to stop this happening).

Its not management's fault of course. They are held hostage to this middle management success metrics of Speed (time and money) by the business leaders who have little else to go on. If only they had a reliable way to measure the RoI...more on that in another post.

The question is not "How quickly can we build the product/service?". The question is:

"How quickly can we build the product/service that the user wants?"

The Real Metric of Success

Efficacy is the real metric of success, and it can be clearly identified and understood by proper UX Research, defined by UX functional architecture and measured/validated by UX usability testing.

Those who prioritise Speed over Efficacy end up delivering neither, and at the same time value, reputation and competitive advantage are lost. Worse than that: it means your competitors can beat you by prioritising modern UX themselves and delivering a more compelling and competitive solution than your company.

Speed isn't delivering a solution faster, its delivering competitive advantage that cannot be easily improved upon.

Limitations

I recognise that there are time and financial limits on every company and project, but project and business leaders are too quick to cut anything that superficially slows down the start of coding, in the belief that somehow this will get them to market quicker and that quicker equals better. Quicker is not better. Don't believe me? Ask your wife.

First you need to understand the requirements and the scope. Then evaluate what the metric(s) of success are for the user and the business in this environment (UX Research and architecture), then and only then, examine how delivery of that success is limited by the time and money available.

You'd be amazed how often we have done UX project post-mortems, discovering that if we had not cut corners (UX being one of them) before going to development, we would have delivered all the functionality the user needed, not a poor MVP or complete code failure. It will become obvious why as you read...

The Types of Speed

'Speed' comes in many forms. Methodologies like Agile, Lean and Design Thinking have sprung up to 'manage' the compromises caused by the metric of Speed, however, only modern UX actually negates it completely...if its carried out properly and holistically.

Design Thinking has done nothing to dethrone the false prophet of speed or prevent this culture of anti-research. In fact it enables this behaviour, encouraging a quick workshop period that delivers no real insight, no validation and empowers project leaders to say they have done 'research' and quickly get the development team coding something that doesn't address the valuable issues, because they haven't been researched.

Agile was created to express how important it was to understand and build to the user's needs, and to give the developers a fighting chance of delivering something useful in the face of the over riding Speed metric. There was no real concept of the UX discipline when Agile came into being but there was an understanding that the principals of UX were missing in most projects before going to code. Of course by the time the project rolls into Developer Town its too late to insist on the importance of understanding the user needs. Modern UX makes sure user needs are fully understood before coding begins (literally a principal of Agile). It even streamlines the Agile process (but that's another post...or chapter). Think of modern UX as project lube: It makes it easier, less painful, quicker and ultimately more enjoyable for those on the receiving end (developers, POs, systems architects, users etc)

Speed Mistake 1: Assumption

Far too many project leaders (PMs, POs, Account Execs etc) have a superficial conversation, focussed on what they can sell rather than what the client might actually need, and then want to get straight to coding a 'solution' as it exists in their heads or as it fits a product they're thinking of.

It is often contemptfully declared that UX research is a waste of important development time (which is much like suggesting that looking left and right is a waste of important road crossing time), that it will only delay the project (development) and reduce speed.

There are a couple of reasons for this in my experience. Some people just want to sell products that their company already make. Their job is not to understand what a user needs, but to understand how they can shoe-horn their existing solutions into the client's problem statement, or shape the client's problem statement to fit their existing solutions, regardless of the efficacy of the outcome. They get paid to shift boxes. Their professional success metrics are directly in conflict with what the user needs.

Or they confidently pronounce that they “know the client's pain points”, having had a workshop or coffee with them, regaling the delivery team and their own bosses with how well they have divined the perfect solution. 'I am a user too'. All they really need now is a subservient delivery team, a deadline and some budget in order to guarantee a successful solution. And they'll use that Agile buzzword to deliver it. They are 'taking a punt' and dressing it up as insight, opportunity and confidence, with a hefty sprinkling of buzzwords. They are motivated by the professional metric of landing as much work as possible, they do not have to worry about delivering it. This is also not the metric of success. Still it is the metric by which their professional efficacy is measured by their bosses and as you can see it is (it very often is) in conflict with the metrics of success for the organisation, the customer and the user. Metric alignment (or rather misalignment) is a keystone problem in most businesses. But that's a different blog post/chapter.

By the end of many projects (especially the big, meaningful, enterprise level ones), much has been missed because critical UX research was undermined to allow development to begin quickly. In the end there is simply lots of finger pointing and a growth in the blame culture. Managers and leaders can't understand why the project turned out so badly or don't want to admit it, so they learn nothing. They wait for the next buzzword methodology to magically save them (Design Thinking, value stream mapping, etc) but never address the underlying problem, so it never can. And they still fail to recognise that Speed was the root cause of the failure, not the metric of success.

Speed Mistake 2: Standing Up The Development Team Too Early

Another persistent example of the Speed metric problem is when project leaders get the development team coding as soon as they physically can. Well before they actually know what they are supposed to be creating, quoting Agile as their mantra: failing fast and failing often (compromising or ignoring UX).

UX research 'gets in the way' of development because they're 'wasting time' understanding and validating what is the most valuable, competitive thing to build. But that means the development team are sitting around burning money (because they stood them up before they knew what they were building - before the UX was done).

Delivery team leaders try to stand up an expensive development team and their expensive development environment, to code a 'working' version (POC, MVP). This is not good agile. Read the Agile manifesto and you'll see. They believe that this is the quickest way to get a product built because they are superficially going straight to code. Of course it takes 3 times longer to do this and costs 10 times as much to do this because they aren't sure of what they need to build. So they iterate till they run out of time/money and eventually they wheel out the hackneyed old phrases like "We just have to deliver something".

And there's more. Because they didn't have a clear understanding of what they needed to build they not only have to guess at the functionality (building unnecessary functionality and failing to build required functionality), they also have to guess what skills the dev team will need, they have to guess what technologies they will use, they have to guess how big the dev team needs to be, they have to guess how long it will take to build the unknown and they have to agree to do all these unknowns to a preset (made up on the spot) deadline and budget without any way of knowing if they'll manage.

So, get a single cheap UXer do this with a single piece of software and test with actual users (quicker, correct and cheaper) and no one has to guess anything. ANYTHING! It's the most efficient way to deliver a project.

Of course the delivery team on the ground usually push back on anything that ingresses on their professional integrity to deliver the best product, using best practices. Its one of the main reasons for the invention of Agile, but soon they fall victim to the insidious metric of Speed and the blind denial of leadership that there is any other way to do this.

Consequences

The problem is that proceeding to development as quickly as possible and then attempting to correct the many false assumptions as they are uncovered is not just suboptimal, it's also not the purpose of Agile. It leads to inefficient 'Frankenstein' code and sometimes it leads to undeliverable code.

It also leads to frustrated developers, compromised utility, an increase in technical challenges, technical debt, software bugs, a requirement for more time and money, a less intuitive solution and consequently a very significant increase in the requirement for support of the product once launched. And ultimately it leads to unhappy customers and users, which will cost the company reputation and cause long term reputational damage. All of which can be avoided by the proper application of lube, uh I mean modern UX.

Speed Mistake 3: Agile - The Verb, Not The Noun?

How often have you experienced middle/project management trying to twist the very processes, methodologies and ideals you use to ensure great products and services to confirm their own opinions?

They tell you that agile means being quick and not wasting time planning. Managers (and others) are quick to use agile the verb and Agile the noun interchangeably. If challenged, project managers/leaders commonly defend the straight-to-code approach with the glib quip "we're supposed to be agile" (verb), as though building something, before anyone knows what that something should do is Agile (noun). Of course Agile (noun) does tell us that "No coding should be carried out while the user needs are in doubt" (that'd be 'No coding should be carried out before UX is done'), so how do project leaders reconcile the perceived paradox of Speed and Efficacy? They ignore it and demand we go faster (to make up for the delays caused by prioritising Speed over Efficacy in the first case). They simplistically jettison anything that takes time, regardless of its importance for ensuring efficacy. UX is usually the first thing to go.

Analogy: You are in a passenger plane that is crashing towards the ground. If you immediately jettison the engines because of the simplistic assumption that they are the heaviest things (and thus must be dragging you down), what will be the outcome?

• They quote tired mantras like "fail fast, fail often", but what they're making you do is fail immediately, fail always.
• They drive the MVP acronym by the M (minimum), not the V (viable or valuable).
• They start to use adjectives like "just" and "only", suggesting that successful delivery is a simple task, only just out of reach, revealing that their grasp of the development process is tenuous at best.
• They can only see a deadline, and all integrity and mindfulness are lost in the rush to make their superiors/stakeholders happy with their ability to deliver on a metric that is an act of sabotage, not a north star to success - Speed. The end user is an inconvenience that can be ignored.

This is project operational expenditure being prioritised over customer satisfaction, organisational growth and revenue.

Do not believe the dime store psychology and the attempts to excuse a total lack of planning (or understanding) by using 'Agile' as a verb to pressure the delivery team to produce miracles in the face of impossible deadlines and poorly understood requirements.

The Affect

Basic efficacy trips them up and undermines this superficial methodology in the end. Inevitably the client (and the users) want to see that the solution delivers on their needs and expectations before it goes live. When the client or users see the current solution they pick big glaring holes in its usability and utility (holes that would not exist if UX Research was carried out and had not been cut for 'slowing down development') and thats when we see 'new requirements' suddenly appearing.

These are not new requirements at all of course, they are requirements that should (and would) have been uncovered by proper UX Research, saving the development team a lot of wasted time in guesswork and code rewrites that are affectionately labelled 'iterations' that leave the solution with unnecessary 'technical debt'.

As the project progresses and lack of data, UX research and insight crystallises in to confusion, changing requirements, lack of clear deliverables and clouded direction, the default decision making tool becomes knee-jerk assumption and much important utility is never uncovered or is uncovered late and cannot be implemented in time.

Speed is blindly given an even greater priority (as it is the only thing that can be reliably measured without UX research) spiralling out of control and in the ensuing panic project leaders blindly insist that the developers deliver the additional deliverables that have come to light, through live testing, and all to the same original impossible deadline. They don't care how (remind the dev team of agile, the verb, here)

Developers end up working long, unnecessary hours, tempers are frayed and there are often lots of management soundbites like "we've got to pull together as a team", "We've just got to make this happen", "We're going to have to work this weekend", "I thought you you were supposed to be agile" and "It's only a simple change". Teams begin to close ranks and prepare their blame statements, practicing them even before the deadline. All totally unnecessary if UX is allowed to work.

The developers not only have to add 'new' (unresearched) functionality but they have to factor it into the current code. It is immensely inefficient to refactor or rewrite code in order to solve a different or modified problem. Discovering 'new' requirements during coding is just about the single most expensive, slow and unreliable way to create a successful solution but a brilliant way to guarantee failure.

As the project progresses the drag of poor choices made on poor or no UX increases and so does the cost and reputational damage. It would be difficult to think of a better way to sabotage a project (it costs up to 10 times more to fix a problem in development than in UX, and 100 times more to do so after go-live). None of this leads to actual speed, just more failure, finger pointing, demotivation and reputational damage.

Ironically, speedy delivery is not hindered by modern UX, it is ensured by it. Embrace:

• Modern UX
• Good UX research
• UX usability testing
• Proper planning around UX insights

The Consequences

Never, not ever, not even once, has the Speed approach led to an optimal solution or anything less than mediocrity (I've worked all over the world in every sector for hundreds of companies). More often it leads, ironically, to projects running out of time and money. But companies get away with it because they are all (more or less) working to the same broken success metric.

And here again you hear the mating call of Projectleaderus Panicus "We just have to deliver something". Well, that something will be curled up and steaming when the client receives it. But it'll be quick. And it will be unfinished and not FFP (fit for purpose) and it'll usually over run and be functionally compromised. The sales team (you remember them - they are the ones who are measured on landing work, not delivering it) will have very uncomfortable discussions with unhappy clients about the delta between what they were promised and what they received.

BUT as the deadline approaches and the 'unforeseen changes' (actual requirements that UX Research would have uncovered in the beginning) mount and developers work long, unappreciated, unnecessary hours to try to deliver something, there is a silver lining...

The Silver Lining

All this professional drama, long hours and using agile as a verb is a team building, bonding, cathartic experience for the whole project delivery team. Many important lessons will be learned from mistakes that will never be repeated again and in the end everyone will praise the developers for their hard work, long hours and give them money and time off...oh no wait...no they won't.

No, there will be no praise (beyond possibly a superficial 'thank you' email, to the managers, not the developers). The lesson that will be learned is that "we need to do this quicker next time" because they will still believe that lack of Speed was the problem, not lack of UX research and testing.

They will simply expect the delivery team to grit their teeth, suck it up and do it all again next time. Because next time it will be faster, because next time they won't waste time with lube.

What's the alternative?

Well, lube obviously, but business owners, stakeholders, project managers and leaders in general need to wipe out this speed-will-solve-everything cultural pandemic and embrace the idea that a clean accurate definition of the requirement is the only thing that truly leads to real insight and thus a successful solution for the customer and for the business. A solution that people will remember for its success not for its failure. A solution that will make their lives better and truly solve problems. And ironically, a solution that will be faster because your delivery team will have received validated insight in to what to build, so they will build it right first time, with the optimal team, technologies and outcomes in the minimum required time.

The business will have valuable insight, so they will deliver something that has the utility users want (and they might be able to use this for other clients). And happier clients leads to more work and more money.

Reputation and efficacy are everything and UX is a comprehensive and defined methodology for delivering them. You just have to employ modern UX methods (and experts, not UI designers).

How a business delivers desired utility at optimal speed

Step 1

Recognise the critical importance and positive impact of UX Research and allow sufficient time to carry it out. We use a formula and a template to estimate the time required for UX research. It is data driven and is invariable accurate (and it's in my upcoming UX Book - little plug there).

It must be Modern UX research based on function, value and utility, not UX/UI assumptive research based on empathy, delight and vomit, or academic research without end.

It must be research designed, transparently, to uncover valuable insights and deliver those insights to the project teams via consistent deliverable artefacts in formats that help those teams do their jobs better and faster.

Yes, speed is the outcome of modern UX.

Step 2

UX Functional Architecture (UX Design in old money - 'Design' is a bad word to use on UX) - don't stand up an expensive development team and their infrastructure before you know what the requirements should be. Its very costly, invariably wrong and no one wants to admit they did it too soon, so you end up just trying to deliver with the team you have and the technology they guessed at to a deadline that has no relation.

Involve a development lead in a consultancy capacity during this phase so they can evaluate the technology and team requirements from the UX research insights. They can accurately estimate the time and costs required, from the on going UX functional architecture (user journeys, functional prototypes and usability testing), allowing them to specify the right technologies and team size, skills and shape with the maximum lead time, saving more time and more money in the long run. Its a powerful collaboration between the architects and the engineers.

Modern UX empowers the right people and processes that deliver the best solution in the least time by giving them the data and insight they need to do their jobs well.

The iteration process (as specified in Agile): UX usability testing needs to be carried out to validate and refine the solution before beginning the expensive process of actually building it, because, as mentioned, trying to integrate changes in to existing code that was built on a different set of requirements, is insanely inefficient, difficult, expensive and unsuccessful.

Iterating through the failed tests in a quick, cheap, real time UX prototype, built with quick, cheap UX prototyping tools, is (guess what...) quick, cheap and produces the most accurate results so the developers can build from fully formed user stories that are right first time.

Modern UX teams create tested, validated functional user stories into the agile/Scrum environment, that will not need to change. The developer and engineering teams can reliably produce technical stories to compliment them. There will be no need to iterate through unforeseen changes, because there will be none. Your expensive dev team will be able to function effectively and deliver optimally because they will know, with confidence, what they need to deliver before they start coding. It will reduce development time by up to 60%. The results will not just be desired by the users, they will have been tested with the users beforehand to prove that they are desirable, utilitarian and valuable. You will deliver guaranteed success.

Following these simple steps, embracing modern UX and allowing UX to do their job before rushing to code will deliver :

• Utility your users want, and more importantly, are willing to part with time and money for.
• A valuable product or service delivered into your portfolio
• Increased customer satisfaction and brand reputation
• Decreased support requirements
• Give you a competitive advantage in the marketplace that's near impossible to better.
• Significant, measurable return on investment
• An effective, repeatable blueprint for optimal project delivery
• And finally, last but by no means least, embracing modern UX will ensure THE fastest possible delivery of something successful, not just 'something' curled up and steaming.

If this article speaks to your beliefs or experience please consider joining the UX Sanctuary UX user group - we'll be launching soon.