The dangers of prioritising speed over quality
The dangers of prioritising speed over quality
Companies are moving to product development models that prioritise speed over quality at every step of the way. They need to deliver to the market quickly to stay relevant and competitive. They also need to ensure they optimise their funding to deliver products and prove their progress to their stakeholders and shareholders.
Sometimes, it is important to prioritise speed to market because one wants to test the product-market fit with minimal investment. This approach may work for a startup or an idea to be tested with a small group of users. It works for an idea with a limited scope. However, this approach has its own downsides when we deal with complex organisations, tech stacks, and problems.
Decisions are made quickly and then regretted later. Products like this may never see the light of day, and teams leave. Funding cuts happen. Ultimately, customers suffer, and a lot of money is drained.
I’d like to discuss complications that result from prioritising speed over quality in a disproportionate way.
1. Funding models that lack generative research and systems thinking leave no space for innovation.
Skipping important steps such as generative research before funding initiatives is not that common anymore, but if it is done by people with a lack of customer research background, it can result in poorly shaped initiatives. Obvious, Complex and complicated problems in the Cynefin framework require different approaches. Complex — Probe, Sense, Respond versus Complicated — Sense, Analyse, Repond. For Obvious problems it is Sense, Categorise, Respond. This means that when you use the wrong approach to analyse the problem before solving it, then you could end up with wrong solution, that may cost you.
Generative research helps shape initiatives into tangible pieces of product/service/experience to be delivered to market because it provides evidence to provide a strategy and a competitive advantage. If you hire a researcher with the right skill set, generative research does not take a long time, and you can create a strategy and definition of success before funding an initiative. Generative research in UX design, (besides user-research) includes doing a landscape analysis, seeing how other organisations or jurisdictions solve for a particular problem space, and then contextualising it for ourselves. The outcome of generative research, to an extent, is also framing the problem in a way that a set of solution options are envisioned besides the original solution idea that could be explored further.
When we prioritise idea formation and put it into “delivery” with templates such as Lean Canvas, we are going small with the problem and focussing on one part of it. However, this ignores the complexity of the world we live in. Especially in legacy companies, the problems are systemic. Systemic could include people (culture), processes, technology, and data. Such quick-fix tools rarely use systems thinking for problem-solving and rely too much on getting a message to execs fast for funding an idea and launching it.
2. The myth of the first mover advantage
First mover advantage means that we need to be the first to reach customers, and that’s how we will capture the market share. Considering there would be no competitors if we were the first, we would attract and retain all those customers in the long run.
Companies that have done things the first time in the market have not necessarily been successful in their efforts, and have had to do more work to achieve growth. Products from companies such as Apple, which are world-renowned and profitable, rarely have the first-mover advantage. They have come in later, delivered a better experience of an existing product, and now become market leaders.
Technology moves at an exponential pace (as opposed to linear), so the first mover myth may have worked a century ago when technology was slow to evolve, but now, this is rarely the case.
3. Over-indexing on measuring success with velocity
Executives may want to see results and not care about ‘how’ some outcome is reached. Middle management and project leaders may confuse this with showing something is ‘complete’ such as tickets and story points on a Jira board instead of delivering something valuable.
Breaking down an idea into smaller deliverable chunks or slices is said to improve the speed to market, creating lots of MVPs. While I agree with this in theory, this works in very mature teams where building, testing, and delivering a small piece of tech will be quick enough (a matter of hours or days) due to the way the platform is implemented and teams are organised around it.
However, whether this actually solves a customer problem and sees significant improvement that translates into ROI is questionable. Would you let customers wait for a full product experience rather than deliver it in fragments? A balance of delivering an end-to-end user journey for a specific feature rather than only improving one part of the journey but leaving the rest up to fate is what drains an experience.
Too much thin-slicing can also create issues with managing customer behaviour expectations on the platform because the platform’s UX gets updated too frequently.
4. Ship of Theseus teams
The Ship of Theseus refers to a ship whose parts were replaced one by one until none of the parts of the original ship remained. So, should we still call the new ship with those new parts Theseus’s ship? It's the same story with non-persistent teams, where every time a new team member comes in, they introduce new processes and structures, which slows progress down.
If you kick off a project with only speed to market as the driver and the goal, team members may be confused about what is expected of them when you prioritise speed over outcome. Leaders may be unable to communicate that they need a working product with an expected result (such as solving a specific problem, a certain level of customer adoption, and/or financial outcomes). Customer adoption needs to be defined so that we know what a successful and happy customer looks like as opposed to uptake/conversion rate alone.
The only thing communicated to them in certain projects is a due date. This turns off the part of their brain that works for creativity and problem-solving and activates on the part that is fight or flight response. As a result, decisions at a leadership level are not made with the level of scrutiny that they need to and this cascades down to the team members too. Nobody feels empowered in their role.
This results in a substandard product because of a lack of persistent teams. Team members leave because they cannot deliver on time and do not have any expectations set besides a fixed due date. They lose their motivation, get burnt out, and cannot have a sense of skin in the game and achievement (which many people come to work for).
I have been on one project where the entire team of developers, analysts, product managers, and project managers left over the course of a year and were replaced over time. The product still didn’t go to market because there was no definition of success besides “delivery by a certain due date.”
5. Technical debt — borrowing from the future to build fast but poor CX
Companies with legacy tech stacks are the ones going through their ‘digital transformation’ process to modernise their technology. Companies born in the digital or cloud are also going through programs such as re-platforming or building something more structured from what is a ‘monolith’.
Decisions made prioritising speed about technology solutions can most likely create technical debt. Companies can then not hire developers to work on their tech teams because the developers are solving half a decade or more of technical debt or making decisions to build on top of it. A few years later, it becomes a case of investing in another platform because the existing situation is too difficult to resolve. I am not qualified to talk about technical debt, but I have heard this from the solution architects and developers around me.
6. Poor quality product service experiences for customers.
This one is a bit obvious and is talked about heavily but isn’t addressed. The market doesn’t want substandard products that go quicker to market. They want a high-quality product and will wait for that and then pay for it. Unfortunately, we’re stuck with a lot of substandard products that were launched and did nothing to even consider customer needs; they only prioritised taking an idea to market at speed. Evaluative research gets wasted when decision-makers only prioritise 1/5th of UX recommendations and ignore the rest.
Ideas are a dime a dozen, but it is the execution that matters!
Products designed and built in haste could result in some risks, which, if not mitigated, result in more expenses to the organisation. One could be less risky, such as simply bad UX, which results in more drop-offs and more Customer Support calls, but also high risk, such as mass security breaches causing reputational damage to the organisation and causing customers to leave in droves. Just because something looks good (visually, UI design) does not mean the user experience is good, and the product succeeds. Vice versa, a product idea that aims to solve a problem may sell well for enterprise customers but could be so poorly designed that end-users waste a lot of time trying to use it and fail, resulting in productivity losses. Metrics such as customer rate of task completion, task-completion time etc also need to be measured to call a product successful and keep evolving it, besides only the ‘engagement time’ on the application.
7. “Who” is doing the work of quality accountability?
Lack of quality standards set, communicated, and accountability for quality, but being accountable for the delivery of something, is the elephant in the room. Hiring people at the top who know “what good looks like” to be leaders of craft used to be big about 5 years ago. They were accountable for ensuring what went out of a team had a certain level of measurable quality against design principles. There was a specific focus on quality of experience that had nothing to do with financial or product analytics metrics.
It seems to be no longer the case in the industry as teams move towards laying off people and moving to one person doing the job of five roles. A product manager or designer may be doing research activities (plan, conduct, synthesise, present insights) plus design (concept, low and high fidelity), getting things ready for developers, managing people and egos, and working through market uncertainty and organisational unreadiness. They cannot be expected to focus on quality at this rate.
Setting financial targets for individuals can incentivize good service experiences, but problems arise when incentives focus solely on speed rather than quality. Not measuring success using customer satisfaction metrics and holding individuals accountable for product quality may lead to a potential decline in customer adoption.
Conclusion
When we execute ideas thoughtfully and take a little more time to do so, we will see more repeat customers, solve more customer problems, and generate more revenue. We will reduce the clutter of many mediocre product experiences in the market and make people’s lives easier and more pleasurable.
Unless we save lives and work in the emergency departments, we need not rush with our jobs. Rushing substandard products and services to market is not helping anyone. Creating a sense of accountability for high-quality product experience and code will create a more sustainable culture of product development and will help not only the customers but also create a long term trust in the teams involved in building wonderful products. While speed is important, quality needs to have an equivalent weightage so that we achieve customer and business goals and optimise the investment in the effort.