It’s hard to create a desirable product. Sometimes you’ll nail it. Sometimes you won’t.
Why doesn’t it come together? Lots of reasons -
Strategy was wrong.
The environment wasn’t understood.
Research was off.
Execution wasn’t right.
No attention to details.
Nobody understood the concept.
Nobody really needed this thing anyway.
To thwart all of the above, its important to start the project asking questions. When we stay open to learning what we don’t know and have a method for doing so, we can start to mitigate the head wind of obstacles that every initiative faces. All astute projects begin with a reasonable strategy that examines the environment, the intended users and is wide-eyed about the inherent risks in the plan.
R.A.I.D and S.W.O.T are two methods for organizing and framing a plan perspective. I recently led a project where my Product Manager presented his Discover Stage findings using a RAID analysis. It got me thinking about the ideal time during a product build when risk statements are best announced and received.
While both of these analysis types have their merits, how should we apply them and in what order?
First, both tie back to the contents of a strategic "discovery" process. During that period, we assess the product or service offering, the business goals, the market and the intended users. That's a major simplification of a deeper set of investigations, however, these kinds of activities inform a product strategy. If you want to know more on that topic, read To Change The World, First Create a Product Strategy. In that article, you’ll also find a template to download.
Let me lay some groundwork concepts to craft my conclusion.
Marketing vs Product-ing
Marketing is different from Product Development or Producting (my made-up word). While they should leverage the same foundational strategic material, the outputs inform distinct ends. They take the basic business strategy summaries and extend it into their unique domains.
Marketing is intended to repeatedly and creatively invite you to dismiss your current biases. Those biases take the form of preferred products, behavior or view points.
Producting takes an idea and transforms it into a focused, usable experience. Product experiences have a functional benefit.
I admit, the lines are often being blurred. Marketing now can take the form of product experiences, though they tend to be a shallower version. A simple example might be when BMW invites likely buyers to come drive their cars at a race track. The user has a product experience, but its a marketing event intended to move the user to purchase.
The reason I want to make the distinction between selling a product and using a product, is that this article recommends when to employ a RAID vs SWOT analysis based on product development needs, not marketing. While my argument may be applicable to communication programs, I don't intend to address that here.
Let's now examine each analysis type.
This is a project planning technique to assess key project (R)isks, (A)ssumptions, (I)ssues, (D)ependencies. It allows a team or product manager to do an initial scan of the environment – both internal and external – for the purpose of alerting everyone on how the whole effort may go sideways. It looks at things like the proposed schedule; the skills needed to execute effectively; the technology stack; major dependencies that may not be fully understood; and other elements that may change over the course of the project.
RAID analysis, by its very description, is focused on what could go wrong to thwart a project from being developed according to the initial plan. It assures that everyone involved has their eyes wide open as to what must be resolved for this to come together. Ideally, when a RAID is presented, it is done so assuming the agency's product manager and the client lead can jointly work to address the identified issues.
I'm a firm believer that it's bad form to point out a bunch of problems without proposing a process for solving them.
This is the other, most commonly used type of analysis. It's a study undertaken by an organization to identify its internal (S)trengths and (W)eaknesses, as well as its external (O)pportunities and (T)hreats.
SWOT analysis is structured to provide a focused lens by which to refine the strategy, whether that be communications or a product proposal. In fact, I have used a version of SWOT when accessing the feasibility of a new idea that has yet to be built. On my personal site, I share a template that outlines seven steps to make you a strategy superstar. It's both useful for entrepreneurs and for incumbents who are looking to pilot new products or services. I like these types of frameworks at it helps assure that the idea is sound.
When to Use Which
When my project manager used a RAID at the start of a project, it struck me as the wrong time. That moment lead me to consider this very article.
Client relationships are like marriages. There is a distinct honeymoon period when we're all excited and optimistic about a successful outcome. It's an awesome moment! Creative service firms need to capitalize on that feeling. Early in a relationship, we want to focus on the creative possibilities that can solve a stated goal. We want to optimize and build momentum.
What we don't want to focus on are all the things that could go wrong. That's exactly what the RAID list did when presented at the start. There is a right time for a realistic set of concerns that will cause a project to fail – but not at the start of the marriage.
I would argue that in client services work the time to present a RAID is after a proof of concept* is built. At that stage, there is creative momentum and a proxy for the full product that can reveal what could go wrong. Those issues must be addressed prior to building out a functioning prototype and then the full build or MVP.
The SWOT analysis is a bit more objective and, in my opinion, comes with a bit more positivity. It has a "can do" feel to it, but with a dose of thoughtful reality that everyone can logically get behind. I believe it has a valuable role to play near the start of the project, preferably as part of the Discover Stage conclusion.
And that leads to the epiphany I had several weeks ago:
Use a SWOT analysis to clearly articulate the opportunity.
Use a RAID analysis to mitigate and resolve risk.
I tend to take complex things and apply them simply. Frankly, its also easier to remember when you're in the "fog of production" and clients are throwing out every idea they've ever had while your team is scrambling to sort out all the pieces on time and on budget.
Remember – keep positive momentum throughout the project by using the right tool at the right time. You wouldn't start coding at the start of a project. You wouldn't write that code with Adobe Illustrator or Sketch. So why present information out of order?
I hope this has been helpful. Please write and tell me how you've used these and with what kind of outcome.