Compelling Strategy Design

Written By Richard Cunningham

What is strategy design? Why should an organization undertake it? What role do business analysts and architects play in it?

This interview with strategy designer Janeen Marquardt answers those questions and more.

 

Interview Transcript

Introduction

PA: Hello, I'm Richard Cunningham, Chief Blogger for Purposeful Architect, covering the early stages of software development, namely business analysis and architecture. Salesforce promotes strategy design before starting any of these activities. They even offer a strategy design certification. So I've invited Janine Marquardt to discuss strategy design. Welcome.

JM: Thanks for having me.

PA: Tell us a little bit about yourself.

JM: Sure thing. I've been working in the Salesforce ecosystem as a consultant for more than 12 years, but I've actually been a user for around 20. I did, however, start my career in technology as more of a technical project manager and business analyst. I've been in the Bay Area doing the high-tech startup thing for like 25 or more years. So while I might now have 9 certifications and be a 4X Ranger, I was actually a certified PMP first. I have been in a lot of companies, some of them large, some of them small, you've never heard of them before, But that's the way it goes here in the valley, you know. Easy come easy go.

What is Strategy Design?

PA: Let's dive in. What is strategy design?

JM: At its core, it really is just a process of creating a plan or approach for a company to achieve their specific goals or set of goals.

Why Strategy Design?

PA: Why should an organization engage in strategy design?

JM: I think that there's a lot of reasons why an organization might engage in strategy design. A lot of times it's because they're starting out on something new. But sometimes it's because they are realigning themselves to where they want to be. Maybe they want to achieve some specific goals, like achieve more market share, increase productivity, or just stay competitive in general because the market is constantly changing, They might want to just increase that efficiency, as I stated earlier. They might want to foster some innovation, see if they can create some new product lines or some new ideas, some ways of approaching their business. But at a bare minimum, they want to also make sure that they're improving their engagement, their communication, and alignment within the company as well.

Selling Strategy Design

PA: So how do you sell strategy design to executives and stakeholders when they're anxious to start development?

JM: I think it's important for them to understand the benefits of what strategy design gets them. Much like you wouldn't start building a house without a plan, or you wouldn't start an office move without a design. Strategy design really is the plan, so you can't just jump in and start implementing a new system. You can't just start implementing new processes without understanding why you're doing those things, what the benefits are of making those changes, what your end goal is to do them, and how you would align all of your systems and processes behind that so that you can achieve those set of shared goals.

PA: And you want to make sure you don't have any false starts or really strategic errors?

JM: Honestly, errors are OK as long as you understand what those errors are, how they may or may not take you off of your plan, and how you want to readjust to get back on your plan.

PA: I get the impression when you're planning, to make a change in the plan is a lot less costly than making a change in the finished product, to take it to extremes.

JM: I mean, absolutely, it's always a “measure twice, cut once” that applies most certainly even in software. You know that the problems get more expensive the further into the implementation you go. 

So if you can do a better job of designing your strategy and your plan upfront, you know a shift left, if you will, in terms of that planning process, you're going to ultimately have a better outcome at the end. Most software projects fail in the early planning stages, not at the end as most people sort of perceive. But it really is at the beginning, even though they might not discover it till the end.

How Much Strategy Design is Enough?

PA: Exactly. I think when software projects fail, you see it at the end. And you know the most common case is “this isn't what we wanted.” Maybe it has nothing to do with our strategy. I think there's all sorts of reasons for that, but I think you're right. 

But then the question becomes: How much strategy design is enough to get a return on the time and energy you've invested in?

JM: Yeah, I don't think there's any one right answer. I think that it really depends on the size of the approach, the size of the engagement you're looking at, the size of the change you're trying to envision, and depending on what it is you think you need in order to do that right, I think for example, not everything in [the Salesforce] Trailhead about strategy design applies to every single engagement that you're looking at, or every single new project. 

So I think you've got to really understand what is it that we're trying to achieve from a business standpoint. What is the business problem we're trying to solve? Then decide what it is we need to try to do to get to that end state. So, first off, do we have a vision? Do we have a mission? Do we all understand that? Have we sort of engaged across the company and does everybody align on that and understand that and can they communicate it? If not, that's your starting point. And you work your way across from there. You want to do as much as is necessary to be successful and as little as is necessary as to not overrun your budget, right? You need to find that right balance.

PA: Exactly, and that seems like the tricky part of it. That is, how much do you invest upfront when there's pressure to deliver a product or a solution that everybody's anxious to get? We got Salesforce for example, and building things is easy. Let's get on it. 

Let me throw an example at you. We have sales reps complaining about spending too much time and energy on producing quotes and escalate it to the sales VP. And one thing that comes up that I think points to the problem is, they said, “We got CPQ [Configure, Price, and Quote].” Now, is that really the right answer?

JM: A lot of things will depend. So when I would go into a company, first of all, I would assess whether or not CPQ is the solution to the problem. So what's the problem we're trying to solve? If part of the problem is we're spending a lot of time on quotes, I would say, “Why? Where in the process is the time being spent?” Is it because our products are complex and it's really, really difficult to quote them because we have to do complex configurations? Or is it because we're going to multiple systems to get pricing and information? Or is it because there's a lot of manual processes for approvals? 

So for a lot of those things, though, the answer might point us to CPQ, or it might point us to a different tool. But very often CPQ is a really good solution to those problems. But I want to solve the process problem first, right? Why do we have the process problem that we have? 

Very often what we're finding now especially is that the processes that were put in place were as a result of software limitations in the past. Or processes were put in place because we were working around what we had. So people forget because sometimes new people are now there, that the processes they have aren't the ideal processes, they're just what they have. So we have to first reformulate the process in a way that supports the business and then come in with the technology solution that supports that process. It's not the other way around, right? 

Process drives technology, not technology drives process, but it used to kind of be that way because we were so limited. But one of the things that's beautiful about Salesforce is that it's a little bit limitless. It's also one of the challenges: you have to understand when to stop. You have to understand when to say enough is enough.  We're not going to go crazy here. We're going to keep it simple. We're going to create that process, we're going to support that process. We're going to see what it feels like to use it and what else you need down the line and slowly, iteratively add to the process, add the automation, or add some of the additional things that you think you need as you use it, and that's a better strategy than throwing everything, including the kitchen sink in at all at once, because we think we need a new system. Just take this thing that we're doing here and put it in CPQ. You're gonna have all the same problems.

PA: Right, with even more complexity.

JM: Absolutely, and harder to maintain because CPQ and Salesforce is not exactly a straightforward easy system, I'll be honest. I mean it is very complex, but it's complex on the back end to make it simple on the front end. It's a trade off.

PA: Right, and I think you asked a key question embedded in your answers, like “what do you need?” I cover this in my blog quite a bit because I think people often come up with things they want from a solution, not what they need. I think, wouldn't you say that need determination would be part of a major part of strategy design?

JM: It's the first question I ask. What is the business problem we're trying to solve? I think a lot of customers come to us with a solution. You can take that down to the lowest level of detail and say a lot of times customers especially, we hear this when we talk about an admin,” I need a field,” “I need a pick list.” I need this. I need that. That's a solution. Don't come to me with your solution, come to me with your problem. 

I'm trying to send a notification to somebody when I have completed a certain other process. Great, there are multiple ways we can solve for that. Let's talk about what we're trying to do. So the same thing happens at the highest levels. What we want to try to do is understand the broader business problem and start narrowing that down to the underlying processes that feed it and get down to the pain points, what's working, and what's not working, then figure out from there, and what do we need to do to solve it? What are the possible areas that we can use as solutions and what are the right tools to do that?

Strategy Design’s Downstream Benefits

PA: How does strategy design save time in the later development processes?

JM: Well, you're not going back and having to rethink where you're going next. If you've done your strategy work upfront and you know what the problem is you're trying to solve, and you've done enough pre-planning. In an ideal world, you're not getting halfway through development and going, “Wait, what is it we're doing here?” So hopefully sort of structured it out. 

I mean in the same way again with a home, right? You don't start planning the kitchen, building the kitchen, and then going back - OK, now where are we putting the bedrooms? I mean, you plan it, you plan the whole structure first and then you build it. And then you come back in and decorate it, right? You don't finish the kitchen and then come back and build the rest of the house.

I mean, you really have to think through the planning and that's not to say that an agile methodology and software isn't still feasible to a certain degree. I mean it is, but you still want to get a really solid plan for what it is we're trying to achieve. Are we building an office? Are we building a house? Are we building a dog house? These are three different problems we're trying to solve. So we really have to understand what we're doing when we start, and make sure we have a good plan in place. But the details, when I first make that blueprint for that plan, I don't have to know what color tile I'm putting in the kitchen. That's a detail I can figure out later.

PA: And you could say the same thing about a UI because some people dive right into the user interface and say, “Oh, we got to make sure that the colors are right and the branding.” You can get to that later. You gotta make sure what you're building does what it's supposed to do, and more importantly, meets the users’ needs.

JM: You can also balance that against the idea of that user experience, right? You want to differentiate a little bit user experience from UI right because there is an element of user experience in strategy, right? We're trying to solve the customer's journey problem to a certain degree. Whoever that customer might be, that's the same thing you're doing in the house. Does this flow nicely? Is the bathroom located in a convenient spot to the bedroom or to the kitchen, etc? So you are thinking about the overall flow of things. 

In both scenarios, right up front, what is the experience I'm trying to achieve? What is the solution that I want to have even though I'm not designing down to the specific interface right? Is this a gas stove or an electric stove? I don't have to decide that now, but I do know that I need to leave 48 inches in a gap, right? I know that the experience is that I want a professional stove versus a small stove, an apartment-sized stove because it's a larger home. Or whatever you're building. So there are certain things you have to figure out, and there are other things that can wait.

Business Analysts and Architects’ Roles in Strategy Design

PA: What role do business analysts and architects play in strategy design?

JM: You would actually be surprised how important they can be in keeping the strategy in alignment. Business analysts can really assist a lot upfront, especially with conducting some research and analysis of the industry such as marketing competitors and assisting with the current state of things. Maybe some SWOT analysis you know, strengths, weaknesses, opportunities, and threats. 

We really have to understand the business in its current state and what is and isn't working. And that's a really key element where I rely heavily on my business analyst to collect that information and put it together cohesively. 

Then on the architecture side, I really need their help to take a look at the organization’s systems and understand where they're at now, and also think about areas where we can make those better overall, because I'm not just looking at the one thing that the organization has said, come look at this CPQ thing. I really do try to look at the big picture. It's really important. And so that architect is uniquely qualified to help me look at that big picture as well. Where can we improve the broad experience for our customer and see if there's broader systems and processes that might need to be developed or improved or modified to help achieve the organization’s strategic objectives.

All of these things working together as a team, help us keep the overall project in scope, keep the team in alignment, keep us on budget, and on track during the actual delivery. Because we need to all work together, not just these three folks, but everybody else on the team to make sure that we can actually deliver what the customer ultimately said that they wanted in the beginning. As well as the additional value of making sure that they're going to become a long-term relationship customer of ours at the end of the day.

Strategy Design Summary

PA: All right. Why don't you recap the benefits of strategy design?

JM:I will try to do that as quickly as I can. Basically, strategy design is a process that relies on an organization to think really critically about what it is that's going on for them, but to also be creative and think holistically in order to make sense of their complex problems. And to work together to create a road map that helps to achieve their goals and objectives.

PA: Like a path, you know?

JM: Absolutely, yeah. 

PA: Going back to the previous question, would it be fair to say that particularly the business analyst is going to keep the stakeholders on the path? Because you can have a successful strategy design, come with up a path, a great plan, and then people deviate from it.

JM: Right. I mean it's a little bit everybody's job, you know it's helpful to make sure that everybody understands and has a common alignment on the vision, the mission, and the goals of the company. Everybody can talk about what the strategic objectives are and that everybody's working together. 

As we deviate from it, as is common as part of the process in any agile world, we sort of tap a little left and tap a little right as I like to say, just to stay on the path. That's why I like to do a long-term road map. I'd like to understand where we're going off in the distance. That's why you have an MVP [minimum viable product]. Here's where we're going first, this is our first step. We have to take the first step and then we take the next step and we just keep making little adjustments as we go and that's why It takes a team.

PA: Yeah, and that brings to mind another question: is strategy design just a one-time thing you do up front and that's it, or does it recur?

JM: It should be recurring. Depending on how frequently you've done it in the past or whether you've done it in the past. I mean, if you've got a specific engagement that's coming up, you may undertake a strategy engagement where you initially put together this road map. Here's our next five years or 10 years. Here's the plan, and here's what we're going to do. And somebody should be checking in. Like I said, this could be during the engagement or during the implementation phase. This really could be where your business analyst keeps an eye on it or you could have a strategist engaged. This will vary a lot depending on the size of the customer and the engagement in your team who plays this role and who's capable of playing this role. Just keep an eye on the prize, right? 

It's like when you're driving down the road. You know you're not looking two feet in front of you. You have to really be looking far in front of you at the same time, right? You gotta make sure that no one's jumping out. You know, no kids chasing their balls. You don't want to hit somebody, but you also have to look far down the road. You've got to be able to keep both things in mind at the same time. 

But it's always fair to kind of keep reassessing your strategy because the markets change and the competitive landscape changes and your strategy, and your goals may change, right? And so you have to keep up with those things. You can't just let it become stagnant. So it's definitely fair to reassess on a regular basis. 

And I would hope that a company already in theory has things like a mission statement. So my goal isn't necessarily to change what their strategy is as a business, but to make sure that that I understand it and make sure that they and everyone in the organization understands it and everybody can speak to it and that it is still the right strategy to achieve their goals. 

But remember that a strategy is not a goal. Right. As the goal might change over time so must a strategy change to achieve those goals.

PA: Right. So as the goals change, the strategy changes. 

Janeen, I really appreciate you taking the time to clarify strategy design for us today. I've learned a lot and I hope everybody else does too. Thank you very much.

JM: My pleasure.

Richard Cunningham
Previous

Lean Business Analysis
Next

What to Expect from Einstein GPT