When clients engage Cake & Arrow as a business partner, they are often looking to replace something old with an exciting new product that will help them exceed a multitude of benchmarks. The challenge of a full rebuild and the benefit it can bring to an organization is exciting, and something I find compelling as a product manager. And while product rebuilds have the potential to be very rewarding for our clients and ourselves, I often see clients fall into a common trap.
When embarking upon a product redesign, companies tend to do one of two things: either they try to paint with too broad of a stroke, abandoning business needs and practicalities for the allure of big-picture thinking, or they get mired in the details, too focused on system requirements and functionality to develop a solution that truly addresses their needs and enables business objectives. A tension between the two often emerges at the start an engagement, when clients either ask for a fully defined solution, or ask us to throw everything away, to “think big.” In my experience working end-to-end on these initiatives, it is critical that, as product managers, we help our clients strike the right balance between the two approaches.
The shortfalls of big-picture thinking.
Within product design, big-picture thinking is considered the holy grail of transformative innovation, but from a project structuring perspective, as new stakeholders and resources are working together for the first time, when the picture gets too big, the project can falter.
In the workplace, big-picture thinking is commonly considered to be a necessary mentality companies must adapt if they want to leapfrog today’s paradigm into tomorrow’s crowning achievements. But in reality, many organizations unintentionally use it as a way to bypass true alignment with their business needs, and in the end, fail to achieve clarity. While the allure of operating in big-picture thinking mode is real, as a product manager, there are some guidelines I recommend to any client looking to implement a drastic refresh of their product successfully. It’s what I like to think of as big-picture thinking with constraints.
1. Align all stakeholders on what the initiative should accomplish and discuss trade-offs.
Instead of defining a directive from the executive team, I recommend first building a hypothesis, and then validating it. To get there, take some time to discuss what the project is and what it is not. Remember, by replacing something that already exists, each business function has a unique relationship with that product that must be transitioned and it is crucial to align different stakeholders on what this will look like. Be careful though, this is not to be confused with a requirements gathering session. We still want to keep this at the level of “Why are we doing this?” instead of “This is what we are doing.”
A few questions I recommend answering as a stakeholder: What does a successful product redesign mean to your team? Why do we need to do this now? What happens if we don’t? What are the most important outcomes you’re seeking? Why might we fail? What aren’t we solving?
At Cake & Arrow, we discuss these kinds of questions during what we call a Goal/Anti-goal session. Anti-goals are meant to explicitly state what we are not after alongside the outcomes that define success (the goals). We gather these together to spark a discussion and create a safe space for stakeholders to debate their perspectives. More often than not, these sessions tend to quickly surface misalignment within our clients, which we can then use to focus the joint team on the important outcomes we’re looking for. A quick snippet from a previous session looked like this:
In the example above, the bolded items came from the Tech Lead and the CMO. Contrary to what you might expect, the CMO was the one concerned with development, because there had been a history of delivery issues. This not only sparked a healthy debate, but it also provided important context on how we eventually arrived to certain decisions on the project. We also came away from this session understanding that engaging the CMO to prove our tech build is on track was key for inspiring confidence and cooperation on the project.
2. Establish key constraints, risks, and assumptions with the project team and key stakeholders.
This one may appear counterintuitive due to the rise and success of user research, but it is my belief that there exists a fallacy that if we design the perfect experience in a vacuum, then we can adapt that to reality after the fact. In all likelihood, we are letting the designer assume constraints that aren’t necessarily valid, or even worse, head in a direction that is too complex. If there truly weren’t any constraints, I’d be recommending mind control as a way to improve user conversion regularly.
A helpful exercise that can lead to a better understanding of the constraints you are working with is a Facts Assumptions Questions session (or FAQs, we need a better name, I know). This exercise does a few things; first, it forces the question of whether a constraint is actually an accepted fact. To do so, we compile assumptions to start building an early hypothesis, and we learn about what everyone doesn’t know. Getting this list together is crucial, because internalizing our constraints while proving/disproving any assumptions can reshape projects for the better.
It’s no secret that Millennials don’t care much for insurance companies. In fact, recent Bain & Company research found that 80% of Millennials say they would move their insurance business to new entrants that are capable of creating and delivering more value than incumbent insurers, leaving incumbents especially vulnerable to insurtech startups. But when it comes to Millennials, what exactly is value, and how do insurance companies make good on it?
To understand weight and priority to each assumption and question, I recommend a Chip Allocation Exercise. This works by providing everyone in the room with a hypothetical currency (for example, 5 voting dots or $20 in poker chips), then have everyone invest their money in the issues that matter most to them. Afterwards, review the results in aggregate and based upon your findings, determine how to move forward with each item.
From the example above, let’s say that the assumption, “Customers will pay extra for data online versus print” received the most funds. Now as a team, agree on how we can prove that right or wrong. The response may be, “Execute a survey on existing customers to understand current purchasing behavior.” If “Do we need to support a Spanish site?” is the most important question, we can opt to look at the analytics to make a decision. What is great about this activity is that it gets the team tactically focused on validation and knowledge sharing early on.
Understand that as a client, you not only bring your industry experience, but also your expertise in the opportunities/challenges within your company. Uncovering the right constraints is key to solving the problem as joint partners. As consultants, our best work happens when all parties truly acknowledge what the challenges are, where they fall in the list of priorities, and how to flip them into opportunities.
3. Justify all functionality of your future experience and confirm it meets your operational needs.
This one is particularly tricky when replacing a product. Many organizations want to start fresh, but as they get ready to replace their existing solution, they realize how much detail is lacking around the current processes. Casting too wide a net and assuming everything will be translated to the future product is a failure on all parties. This can cause distrust amongst the existing non-project teams and hinder internal adoption of the new experience. Unfortunately, waiting until it’s too late to uncover these needs can force some difficult trade-offs pre-launch.
On the flipside, clients often try mitigate this risk by going through the exercise of fully documenting every piece of existing functionality, or compiling features based on consensus to ensure all requests are met. But doing so inundates the team with too many restrictions, making it difficult to determine which requirements should be accepted and which should be challenged.
One way I’ve seen clients avoid this problem is by leveraging Cake & Arrow not only for external user research, but for internal user research too. While all current features are being evaluated, we can use research to come up with a new approach to solve existing employee pain-points, rather than simply documenting an inventory of features to rebuild.
4. Assess the capabilities of your own resources and know how to leverage them.
When it all comes together, you’re not only setting up your partner for success, you’re actually creating a joint-team of internal and consultant resources that work towards a common goal. A great example of this is a recent award-winning engagement with SupplyHouse.com.
When we began the initiative, we understood that the goal was to rethink the User Experience for a set of desktop pages and deliver front-end code for integration. The Supplyhouse team was going to leverage that handoff to apply to the remaining site.
To kick things off, we started as a joint-team with a series of activities that built a full view of the landscape for the client. We removed all notions from the existing site and started compiling constraints and needs from scratch. We also did deep dives into the challenges and opportunities within the industry today to better understand the change that is possible and what is needed. These activities set up some key validation to play back to the team. Pretty quickly we were able to align on the actual crux of the initiative –which ended up being different than we first thought – and delivered delightful customer experience that clearly communicates Supplyhouse’s complex product fulfillment.
How the SupplyHouse stakeholders moved forward here is a large part of what makes them, and us, successful. Balancing this new focus with the expected delivery outlined in our Statement of Work, the internal team reviewed what was considered a constraint of their own technical capabilities. The new conclusion was that the SupplyHouse team did in fact have the expertise to build the front-end code in-house, in turn, reallocating our time to problem solving the purchasing flow and focusing on a cohesive experience. Everyone agreed that this arrangement produced the greater payoff in value. By challenging initial project assumptions, and assessing their internal capabilities, the nature of our engagement with SupplyHouse completely changed and in half of the anticipated time, netted into a much stronger product.
When embarking upon a product redesign, it is critical that the true stakeholders are integrated with all key resources at the onset of the initiative. In our SupplyHouse experience, we would not have been able to pivot the engagement without buy-in from the CEO. The client would not have questioned the constraints of the technology team without proper interfacing of those resources with our technical architect. As the project sponsor, your responsibility is to structure an engagement that ensures high value and yields organizational impact. Typically, this leads to plenty of due diligence upfront and between RFP cycles, procurement, and contract definition, many expectations of the end state tend to get established. By the time the actual work rolls around, it takes a concerted effort to reset and determine what is most valuable to solve. I hope this and some of the activities above help you on your next endeavor as they continue to help us in our partnership with clients.
