.png){kind=logo}
No one wants to headline a new project, or partnership, this way. But the reality is that many innovation efforts, at least initially, fail. Poor UX strategy, broken codebase, poorly orchestrated project workflows–no matter the root issue, things fall apart. If the project is “95% there,” many businesses don’t realize (and can’t truly quantify) what that last 5% really represents.
All of the UX and development capabilities being in place to rebuild, redesign, and revive is the easy part. What dictates a successful rescue mission is proactive, innovative problem-solving and a partnership built upon shared expertise and trust.
Where do you begin? The pressure is high, and the business has been burned. They know the project failed, but they don’t always know where or why. This is what needs to be sorted, but knowing you have to build on scorched earth must set the tone from day one.
This group is coming off a failed project, and they’re in a hole. Lead with emotional intelligence. Listen to their story–as much as they choose to share. Some will show and tell you more than you ever needed to know, while, others might be so guarded that they won’t even show you any part of the “current state.”
New relationships, personal or professional, involve sensitivity and control. In cases like these, the sensitivity to the business’s desire for or lack of control is on you, the partner. Let them say their piece in its entirety before diving into any of your own processes or capabilities.
Once you establish trust and have a full perspective on the situation, it’s time to kick off the rescue plan. Defining an approach, vision, and specific tactics to revive the project is important, but integrating feedback and continuous communication touch-points is essential. Most likely, a breakdown in communication landed them here in the first place.
This is where you identify the root issue and use it to inform your next steps. Whether it’s new UX strategy, auditing the existing code platform, or providing ample justification for the need to rebuild from the ground up, there is no such thing as over-communication or over-emphasis of the goals they have for this experience.
At no point are they going to just “take your word for it.” Providing relevant case studies, data, and metrics throughout the process is going to move mountains.
Sunk cost fallacy. It hurts. This business put hours and dollars forward to manage their first effort, and the bubble burst. As a result, you need to make better decisions–faster. That may sound simplistic, but it’s not. The pressure is on, and you have to put a stake in the ground when it comes to starting over fresh vs. providing solutions for given circumstances.
Business objectives and user experience goals are often, unknowingly, misaligned. Uninformed decision-making and over-complicating the experience leads to many UX issues after-the-fact. These issues can render an app useless. Generally speaking, many companies look to check design and development boxes, but lack the product perspective and context.
Establishing user personas and defining a full spectrum of use cases prior to designing and building an app, for example, is best performed by UX field experts. However, the best discovery results come from having key business decision makers and stakeholders in the room.
But the last innovation partner claimed to do this, and they didn’t. What makes you any different? Integration. The goal is always to get an experience out into the wild ASAP, but in order to do that effectively, you must have a vision. So the “design while you develop and develop while you design” process is working toward a defined goal.
It’s not a step one, step two process. It’s a cohesive flow with open communication and a lot of internal touch points. If the business knows your teams are meeting both internally, as well as with them, at a healthy cadence, confidence soars.
A tiny crack can bring the whole house down–and typically no one within the business can fully audit their technical foundation before a project begins. As a result, a broken experience often presents a mess of “spaghetti code.” Technical documentation has to be established or reestablished, which takes time.
It’s possible the previous vendor may have closed dev tickets, creating the appearance that work was completed, but in reality there was no solid foundation to build upon. Product features can exist in a vacuum, but, even if you somehow make it out of QA, the actual launch (or failure to do so) will paint a sobering picture.
Anticipate and invest in testing infrastructure and automation. Build a regression testing plan and a healthy iteration frequency, together. Additionally, you need to make sure the existing code base gets a full audit, so previous mistakes can be mitigated or repaired.
Part of the problem is an easy entry into coding to make cool things. “You get what you pay for” applies in full for technical expertise and management. Because it’s not all about designing or building a prototype. It’s about anticipating obstacles, using QA to intentionally break things in order to iterate and solve for the worst case scenario, and having a development plan that delivers on the business objective via the best technical solutions.
We’re human. Placing the blame, or owning it, comes natural to us because it creates closure. In the case of failed tech projects, it’s important to take a “what’s done is done; let’s move forward” approach. Being lifted or pulled to safety isn’t comfortable for either party. As a partner, there are things you have to accept that you’ll never know. And, as a businesses, it’s par for the course to be redirected and refocused (maybe even a few times).
Not being able to apply the best practices of your craft and potentially building off of a shaky foundation is difficult, but there are rewards. The ability to be a real partner, build trust, and collaborate to create something great from the rubble speaks volumes. Rescue missions are not glamorous from a creative standpoint, but what these partnerships provide in learning can have a major impact on your work moving forward.
Additionally, the positive results for the business mean everything for their team–especially the person/people managing the project. Righting the ship and setting new precedents after a failed attempt can tell a great story that reinforces value. Not to mention the company now knows what it takes, internally and externally, to get actionable results.
It’s ideal to strategize, design, and build something right the first time, from start to finish. But no one goes truly undefeated. In the sports world, experts say it’s best for teams to lose once or twice to “know the feeling” before heading into the championship game.
Whether a house needs flipped or leveled, it’s not easy. But the end result is a better place to live. If you don’t know what it’s like, as a business, to fail, you won’t grow or hit challenging KPIs. Similarly, if you don’t know what it’s like, as a solutions team, to problem-solve (even under extreme circumstances), you won’t be able to partner with brands who want to redefine their industries.
