Victor Studio

I’ve been asked to share some ideas on the difference between product and business strategy. Here are my initial thoughts… and some examples of work I’ve done to help orgs sort out what product strategy is, and how it derives from your business strategy. Or vice versa.

There’s a newer article where I disambiguate the 7 types of product strategy. This article captures some initial thoughts, which inspired that post.

In this article, I’m using 3 case studies to illustrate how product strategy is often used to drive or clarify the business strategy of products and services.

Case study 1: Rackspace Web Ecosystem Redesign
Case study 2: Home Depot Pro Customer Strategy
Case study 3: THD Pro Contractor Purchase Habits

What is a business strategy?

A business strategy is externally focused; it is derived from looking at external impacts and outcomes. It declares how a product or service will achieve financial success in the real world.

Business strategy typically describes the company’s future vision, growth goals, revenue planning, new investments, market strategies, and so on. It may manifest out of one Big Thing or many smaller things. It may be the founder’s personal vision, a brand promise based on customer experiences, an operational sales plan, marketing & media evangelism, or merely a set of guiding principles emerging from a group of internal visionaries. Or any combination of those things.

It may be formally documented and plastered all over the office on posters and desk swag. It may be executive folklore only spoken in whispers over whisky and golf. The rank and file may only see select glimpses of this secret knowledge. Or it may be so hideous no one dare speak it out loud, for fear of turning into a pillar of salt.

What is a product strategy?

First and foremost, dear reader, your product strategy is not your business strategy.

A business strategy, which is externally focused, is derived from looking at externalities. Perhaps most importantly, business strategies don’t have to answer to (or make sense to) anyone except the C-suite and stakeholders.

A product strategy is internally focused. It looks at the essence of the product itself.
Its interdependent resources. How well the product is situated to satisfy – or manufacture – customer/user needs.

Product strategy asks itself, what is the current fitness of purpose in the real world, and how might we build a more desirable and successful future state?

A product strategy owes all stakeholders an explanation. Especially the entire product team.

In addition to not being the same as the business strategy, your product strategy is also not the outcome of your OKRs or Jira tickets.

There are a few problems with thinking that product strategy emerges from corporate mandates and/or atomic iterative engineering activities.

(1) OKRs are derived from your business strategy and go-forward marketing & sales plans.
(2) Jira tickets (all backlogs in general) are derived from sprint planning.

None of those things will resolve into a coherent product strategy. They are not derived from a planning process driven by the thought leaders on your product team. There is no conceptual integrity. According to Brooks, “conceptual integrity emerges from a small number of agreeing, resonant minds” who lovingly tend to the big picture in which the atomic work takes place. Conceptual integrity emerges from the knowing of its architects, leads and builders and their understandings of the reality of the product’s structure, nature, and capabilities.

Attempting to assemble a product strategy out of Agile sprints is just silly. It would be like looking at a picture of a tree, ordering that tree from an arborist, and then telling the arborist you can’t afford the time or cost for him to dig it up, pack it, ship it on a special truck and have it installed 12 days from now. Instead, you tell the arborist, you want it chopped down and sent through a wood chipper so that it can be loaded into boxes and delivered over the next 4 days in Amazon trucks.

Once a tree goes through a wood chipper, it is no longer a tree, no matter how meticulously it is glued back together.

I’m not trashing Agile or sprint planning. I’m saying that product strategy and conceptual integrity exist upstream, or somehow above and beyond all that atomic work.

I could go on, but I need a break from that quagmire. So I’ll toss in a few examples here.

Case Study 1: Rackspace web ecosystem redesign, 2012

Rackspace wanted to be known as the industry’s most trustworthy hosting experts. But that personality was not well represented to the online experience. The Rackspace web experience was failing to convey the brand’s core value or messaging. Lack of coordination across divisions and marketing initiatives watered down the brand. They needed a UX strategy and action roadmap for a major makeover. I was asked to help them by auditing the site experience and creating a 30-60-90 day action plan to resolve these weaknesses.

Problem #1: What is the Rackspace brand strategy?

If you want to execute on a strategy, you must first understand the strategy. So we had to take a look at how that brand strategy is currently articulated. Was it concrete enough to direct the redesign work?

So, before I tackled the site audit and generated the action plan, I asked for all the relevant marketing and strategy materials they could send me. Then I conducted a round of stakeholder interviews to understand their concerns, goals, and assumptions. Here’s the slide I presented to them outlining the action plan:

At the time of this project, Rackspace had a very succinct brand tagline:

“Fanatical Support”

That was it. The whole brand ethos hinged on this claim. A great rallying cry, but not much of a foundation for an executable product vision. So I asked if there was anything else. The stakeholders then supplied me with a strategic mission statement that the senior leadership team had written for the website redesign project. This put a little more meat on the bone.

And yet, that’s a lot of words. Big vague lofty words. So. Job #1 was to translate the coded jargon into tangible human terms.

I drew out 3 key phrases (marked by me in red) that held the most promise for tangible interpretation in the redesign effort.

I took each of those 3 phrases, those business strategy principles, and derived a presumed set of experiential attributes that seemed relevant – and actionable. I leaned heavily on my past expertise in defining product strategy, with a dash of clairvoyance and a pinch of imagination.

I then followed up with stakeholders to confirm that the high-level approach I’d defined would meet their business needs. The conversations went well, but they approved it so quickly, the pessimist in me wondered if they fully understood the importance of this foundational thinking. Then the optimist in me cheerily added, they probably just trust your genius!

In any case, this formed a fairly solid usable design approach. I could use this as a scaffolding, evaluating the current site against these attributes, and then proposing ways that a redesign could achieve the desired intent.

My next step was to analyze the stakeholder interviews for key pain points, unmet needs and site feature suggestions. Here’s a list of some common feedback themes. Consider how these tie into both the mission statement and its experience attributes.

After this second rinse with stakeholders, building on my initial scaffolding, I pulled together this list of strategic site goals for the redesign.

• Make “Fanatical Support” real on the website.
• Create a consistent, usable, global web publishing platform
• Increase conversion rates and signups across the globe
• Create a world-class learning environment (for cloud hosting services)
• Improve the quality of visitor engagement to maximize leads

Once the high-level redesign goals were approved, I decomposed those into detailed site analysis objectives, carefully worded to guide specific product design decisions.

Once my primary stakeholders had blessed this plan, I analyzed the web ecosystem’s IA, visual and interaction design, and wrote a current-state site audit with specific recommendations.

The audit summary provided concrete examples of page designs, content and flows that could be improved, suggestions on how to improve them, and recommendations on web design and editorial (advertorial) content standards. For the purposes of this article, I will end with the summary of key UX challenges and the 30-60-90 high level recommendations.

Case Study 2: Home Depot Pro Customer Strategy, 2018

In 2015, Home Depot knew they weren’t getting as much Pro business as they could. They had a team of specialists managing their whale accounts, but small to medium pros were not given any special attention, other than individual relationships with the sales staff (the PASAs) at the Pro desk. As one step to correct this, they acquired a little ol’ startup called the Quote Center. The Quote Center had proven its worth to the C-Suite by automating a very important and complicated Pro sales task. They digitized all of the vendors’ special order catalogs. They had a vendor management team, a custom database of all the special order vendors, SKUs and prices, and they built a web frontend to enable digital job quoting at the Pro Desk, instead of thumbing through paper catalogs. It was a brilliant idea and a brilliant success.

Now that they were officially tied to the Mothership, QC had strong ambitions to own Pro customer sales strategy at Home Depot. And they had a real shot at claiming that space.

Of course, it’s very hard for a scrappy startup to make that transition. Unfortunately, the original leadership did not have the savvy or maturity of vision to make that leap on their own. Fortunately, they understood this, and they hired new, more experienced leadership in all disciplines. Unfortunately, they allowed politics to polarize the org as it grew.

The majority of staff were still legacy hires with very little experience outside of the startup, and some aspiring leaders had competing agendas. Soon a political faction rose up among the new PM leadership that wanted to “own the Pro strategy” by themselves, cutting out all other discipline leads. The most senior PM lead was a corporate shark: exceedingly good at managing up, had ambitions of their own. Zero interest in being a team player. Zero passion for building great products. They declared that QC should “be a Marketplace, like Amazon for Pro Construction!” The SLT immediately fell in love with this idea.

It became the mantra of leadership: “We’re a marketplace! Like Amazon!”

But (a thinking person might ask) what does this mean to our vendor relationships? Our data architecture? The application architecture? The user experience, and whether its primary audience would change?

Nobody knew. And the people shouting it from the rooftops didn’t care, because doing the hard work of making sense of their strategy was not necessary; it did not serve their interests.

Forget product strategy. It wasn’t even a good business strategy. Just a sexy-sounding catchphrase, waving benjamins in front of leadership’s faces. It was a terrible idea.

These questions were asked repeatedly by product team leads, who were honestly trying to do serious product work. Data architects, technical architects, catalog teams, UX researchers, designers and systems architects. No one could get a straight answer. Or a word in edgewise.

I spent a year as the UX architect on this product. I analyzed the current product, identified weaknesses, gaps and opportunities for expanding the existing experiences and architectures. I worked closely with dev, data, customer support, etc. to get everyone’s perspectives, build mindshare, and make smarter decisions. But a certain lead PM just kept shining us on.

I made every effort to keep track of the direction the winds were blowing, and I was able to tie some aspects of the work to some aspects of PM’s drunken path of random epics and user stories. But there really was no there there.

Eventually it was time for me to “present a proposed UX architecture” to the SLT. My boss and I knew it was time only because it was my primary end-of-year OKR (not because the leadership team was ready to hear it).

Once I started listing out my deliverables and achievements in the presentation, it became abundantly clear how many were blocked because… there was no product strategy to hang anything on. This was days before the presentation. Working frantically to create a draft presentation for my boss, I was in the throes of a major panic attack.

So I pivoted. Hard. I decided I had to lean into the absurdity, to show the humor of the situation… and to drop the baggage of my dispirited bitterness.

I turned the deck into a status report that explained what I’d done, how I was blocked and why we did not, in fact, have a product strategy. In a fun and engaging (and nonthreatening) way.

At first, I had no idea how to do this effectively, as I hadn’t been able to get through to them for the past year. But a few days later, I woke up from a lucid dream with a brilliant solution to the problem: If computers are theater, then websites/apps are television shows. Television shows have a mood, a format, and a flow of action. Television shows have a cast, a star, a sidekick, supporting actors, and the occasional special guest stars.

So I asked myself, what kind of a TV show would be named “We’re A Pro Marketplace! Like Amazon!” ???

Being a concept generating machine, I took it a step further. How many different television shows could I imagine from a name like that? Within a day or two, I had come up with nine distinct shows, aka viable product strategies. All different. All with different stars, props, core themes, focal points. All with different orientations towards Pros, PASAs and vendors.

Nine different business value propositions to justify “We’re a Pro Marketplace!”

The first slide was a brief description of what I was presumably working to build. What is UXA and how it is intended to influence product vision and design.

Then, a chart to explain where UX Architecture is situated in relation to the QC portfolio, to the whole THD portfolio, and to specific product initiatives. I knew management wouldn’t get it – but they needed to be introduced to these concepts. I needed to document it for posterity.

I then listed the things I was working on, had completed, or were blocked. Then I covered the slide with the question that my stakeholders were casually asking themselves anyway.

Here’s an excerpt of the strategic options I presented to my stakeholders and bosses. This illustrates two separate perspectives: At a meta level, why that the emperor had no clothes. At an executional level, where the current “strategy” falls apart, and how we can fix it.

These slides introduce the 9 potential strategies using established TV tropes.

A few example slides elaborating what differentiates each of the 9 different approaches.
This was a difficult conversation because the differences are subtle, and there are overlaps. But just like ripples in a pond, the differences between these approaches get a LOT bigger when you start building these assumptions out into software. A product that tries to be everything to everyone ends up solving nothing for anyone.

These six examples represent a range of clear orientations to the problem space.

At the end of the presentation, I invited product management to engage in a conversation to define a real, actual product strategy based on the work I had done.

The last slide had the prompt for our next (first) cross-function strategic conversation:

“Which one should we build in 2018?”

30 seconds later, my stakeholders blurted out ALL OF THEM. And then they left the meeting.|

Because of course. WE ARE A PRO MARKETPLACE! LIKE AMAZON!

It’s hard to write about this one, even 5 years later, because I still believe in my heart that the strategic work I was able to deliver – with a hostile PM cohort fighting me every step – is solid fucking gold.

Our leadership completely squandered that gold. Squandered the very real chance we had to be THE Pro thought leaders at Home Depot. All those wasteful, petty office politics caused the whole op to fail, and cost us our jobs.

Within the year, 75% of Quote Center’s staff was laid off, and a rival team back in Atlanta took over the Pro Customer strategy work.

A world-class UX Director, sacked. Two world-class UX Principals, sacked, both vowing to never work a FTE corporate job again. A third UXP had quit in frustration 9 months earlier). Three Technical Architects. The entire leadership of the data team. The place was gutted of thought leadership without any concern for the consequences.

I used to think I just needed a better class of customer or employer, ones that respected the hard work of building smarter strategies for better quality products, services, systems.

What I have learned over 3+ decades is that these are far more rare than anyone wants to admit. In fact, the industry continues to deform and devolve these concepts in the name of Agile expediency. It’s a trap.

Case Study 3: THD Pro Contractor Purchase Habits, 2018

Here’s another case study from my time at QC. Our founder and General Manager, Nate, had a lot of ideas about how Home Depot’s Pro customers operate. Nate’s bosses decided they should have a customer journey for Pros, because they heard chicks dig customer journeys. But seriously, they were drawing up boundaries to determine what part of the Pro Customer relationship Quote Center would own, and what part would be given to rival Pro teams in Atlanta. Not the greatest way to design a Pro experience, but these things happen.

So the C-suite had asked Nate to explain the Pro experience so they could agree on which bits QC would own. Now, Nate had built two companies from scratch, one of them being a construction company, so he certainly had some Pro cred. But to no one’s surprise, Nate grossly overestimated his own domain knowledge, and grossly underestimated how differently other Pros operate in real life and across other types of Pro work that he’d never done. Unfortunately, he had already presented it to the C-suite, without consulting any of his own UX experts, SMEs or product leaders.

Of course, this immediately raised eyebrows. Based on previous field tests & store visits, we knew the customer data in our quoting system was flawed. For example: Not all quotes get converted. Not all Pros with low spend levels at THD are small businesses. A lot of our data was just bad, such as: Not having the Pro in the right business category. Not counting the collective spend of all Pro accounts tied to one business.

The UX team joined forces with the Data team, the Catalog team and the Customer Service team to discuss this model and its ramifications. Data and CS teams were able to come up with sales numbers and demographic data to make the case for field valication. As a result of that work, we were able to convince leadership that we needed field research. I say we convinced them, and while that’s true, it was really my boss, who was a genius and a miracle worker, who won the case for the team.

I led a 3 month field study of Pro customer behavior… which yielded a goldmine of Pro behavior insights. I will only share a tiny bit of that work, in hopes it will be clear how this relates to the tension between business strategy and product strategy.

Leadership’s Baseline Assumptions

Here’s the model of Pro customer spending upon which he was about to bet the whole farm on. I would call this a statement / artifact that overlaps both business and product strategy. And in this case, does not serve either one all that well.

Pro Job Model validated by field research

Here is Nate’s imagined job model mapped to real-world job models of Pros we met in the field. The four clusters (horizontal rows) are behavioral clusters that emerged out of the research. We found that Pros in these clusters bought materials for jobs in the same ways, even if they weren’t in the same line of business.

As you can see, there were several key insights that we brought back to the team which had a significant impact on our Pro business and product strategy. As previously noted, these insights directly contradicted key assumptions that executive leadership was using in their strategic planning sessions.

Had we not performed generative research and strategic analysis of the Pro market, we would have spent the next year building product based on that flawed model. The results would have been devastating to the product experience, damaging to THD’s pro business and dangerous for the future of QC and its employees.

Here are a few specific examples of what leadership got wrong about Pro behaviors.

1. All Pros plan jobs and buy materials in a consistent, predictable sequence of steps. We can use this model to predict Pro spending and engagement with our app at the Pro desk.
2. All job purchases are made by one Pro: the Pro that “owns” the jobsite and client relationship.
3. When a Pro asks for a Job Quote and it doesn’t convert, it’s is a failed sale. Conversion is an important metric, and we should push harder for quote conversions.
4. The size of a Pro’s spend at Home Depot tells us how big their business is.

A few insights from our that debunked those misconceptions.

1. Pro project planning and purchasing is far more complex and varied than assumed. We identified several key patterns and trends that point to new ways to increase job spend.
2. The quoting and “job sale” model in our current app and data architecture does not fit the Pro’s mental model. If we revise our data architecture and project concept in the interface, PASAs can sell more job spend to our Pros by working more closely with them, in the way that they think about their jobs. In this way, PASAs can better anticipate Pro needs – and avoid tone-deaf sales tactics.
3. Our “quoting conversion rate” is a red herring. Pros see job quotes as a sales and estimating tool, not the first step of a purchase. Many of our “failed conversions” were just separate transactions to buy the same materials. The product architecture should not revolve around quotes, as it does today, but should be based on Jobs, which require a complex many-to-many relationship.
4. Our customer data tells us very little about Pros. Making any sort of assumptions from existing Home Depot data about a Pro’s size of business, or even line of business, is a fool’s errand. There are large Pro accounts that spend a lot with us, and large Pro accounts that spend very little. PASAs may be interacting with accounts as big as the ones that the Customer Specialists are often assigned to.

This next section debunks the wrong (and costly!) assumptions about what THD thinks a Job is, what is a Pro, how are Pros related to Jobs – and most importantly – how does spending flow through a job?

Those labels exist as objects in a relational data model that is totally incompatible with reality.

Product strategy must be compatible with reality. Assumptions about reality must be scrutinized. Business strategies can learn something from analysis. Sometimes business strategies should be based on, or adapted to, product strategies. This is (was) one of those times.

A crude representation of the data relationships before research (current product) and after research (true complexity of reality) for jobs, projects, quotes, and accounts. Updating the customer and job models with this info could have been a game changer for growing Pro business.

This was excellent work conducted by a team of 4 competent UX practitioners over 3 months. Had the findings and knowledge we uncovered been absorbed by QC’s leadership, it could have saved over a hundred jobs, and arguably, the entire line of business that they lost.

Small to medium Pros would have loved the product changes that this work was proposing, because they directly addressed unmet needs AND major breakdowns in the current Pro buying process at THD.

IN PLACES WITH NO STRUCTURE FOR STRATEGIC THINKING OR DISCUSSIONS, STRATEGY MAGICALLY EMERGES LIKE FLOWERS IN SIDEWALK CRACKS. SOMETIMES THEY SPREAD AND SOMETIMES THEY GET STOMPED. WHY AM I SHOUTING

(will need to edit this when I’m less tired…)

THERE IS A LOT OF MINUTIAE HERE – THE SLIDES ARE FROM ETHNO RESEARCH REPORT. WE DEBUNKED MANY WRONG IDEAS WIDELY HELD AT THD ABOUT PROS. WE UNCOVERED KEY INSIGHTS – THE WHOLE EXERCISE HAD TO MITIGATE THE SHORTCOMINGS OF LITTLE TO NO USABLE – AND ALSO VERY WRONG – BIZ STRAT. IN ADDITION, WE HAD TO MINE FROM THE FIELD STUDY THE RAW MATERIALS FOR CONJURING A PROD STRAT AND APPLICATION ARCHITECTURE OUT OF THIN AIR.

.