• http://business901.com/wp-content/uploads/2015/06/MWL-5-Pack990o.jpg

Jobs To Be Done Matrix

I have been pretty vocal in the past about using Value Stream Mapping, Value Stream Mapping should be left on the Shop Floor, and along with a couple other blog posts, Shaping your Customers Vision and Kill the Sales and Marketing Funnel. I think these types of tools lead us down a precarious path when used in sales and marketing. The approaches prematurely foresees a solution for the customer without ever understanding their needs.

In the Job To Be Done Thinking created by Tony Ulwick (What Customers Want), Ulwick claims that these three distinct outcomes are what organizations need to know in their marketing practices. Expanding on them….

  • Jobs (to be Done) are the tasks or activities that customers are trying to get done
  • Outcomes are what customers are trying to achieve
  • Constraints something that may prevent a customer from using a product or service

If you would like to learn more about JTBD thinking, I would recommend following Mike Boysen’s blog, Effective CRM. In one of his past blog posts, The Customer Process: The Five Things You Need To Know Now, he discusses the use and importance of Mapping. Many might seem a direct contrast to my above thoughts. The problem that I have always had is that all this mapping and journey stuff has typically been done without the customer involvement and/or a method to validate the assumptions we make. How I solved it presently for myself is with an old tool, Logframe Matrix that I have waffled using for a decade or so. I had first used it working with Non-profits and later revived it as I worked on some outcome mapping tactics. A quick description of the process:

A LogFrame Matrix is a document that outlines the key features that lead to a project achieving its goal. A LogFrame consists of a 4 columns and 4 rows.

  • The first column represents the hierarchy of activities to outcomes that needs to occur for the project to succeed.
  • The second column represents the indicators that are appropriate measures of whether the activities, outputs or outcomes have been achieved.
  • The third column represents the data source or means to verify the indicator.
  • The last column outlines the assumptions that need to hold true for that particular activity, outcome or purpose to occur.

LogframeThis reminds me somewhat of a SIPOC (Suppliers – Inputs – Process – Outputs – Customers). The SIPOC offers a high-level view of the process, and I always recommend using before the mapping process begins. However, the LogFrame could be used to validate the steps of a Customer Journey Map, after the mapping event and as we put our findings into action. It allows us to test our assumptions and put some granularity to our mapping process. I did an outline based on how a Job To Be Done LogFrame is viewed.

Job To Be Done

The objectives, of course, would look a little different. A short description follows:

Who the Customer Wants to Be: Michael Schrage, author of Serious Play, published a book taking these concepts one step further. Who Do You Want Your Customers to Become? challenges us to take our value proposition of use to a longer term growth platform. He dares us not only to have a corporate vision statement, but a customer vision statement saying that our future depends on their future. He phrases all this in something he calls “The Ask.” I discuss this concept in more detail in a blog post, Shaping your Customers Vision. When we flip this thought to Job To Be Done Thinking it allows us to have that impact statement or that larger goal that our customer is striving to achieve.

Job To Be Done:  JTBD is broken down into a couple of components. The Main jobs would describe the tasks that customers want to accomplish, and the Related tasks are what they want to accomplish in conjunction with the main tasks. They can be further broken down into social, emotional and functional aspects. Depending on the complexity, we could make a separate LogFrame for those components but you can have separate multiple Jobs to Be Done on each LogFrame. Since, I usually start with Post-it-Notes, I sometimes will color-code them based on the social, emotional and functional aspects. I will also keep the color-coding for the remaining two steps if needed.

Outcomes: The specific results of the activities ? used as milestones to what is being accomplished during the process. these remain the same concept though I may have current, intermediate and long-term outcomes.

Activities: The actual tasks to produce the outcomes. This is usually a high-level view and can be turned into a project plan or a Kanban board for execution.

I am in the process of creating a generic outline to follow in more detail, but this is just a starting point. What are your thoughts? Does this add some opportunity for better measurement and verification? Could you monitor and evaluate your efforts better this way?

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Sales Collaboration Using Explore – Exploit – Export

I like to use the term EDCA (Explore-Do-Check-Act) learned from Graham Hill to designate the Explore aspect of Lean. I view it as more of Design Type thinking content that allows for that collaborative learning cycles with a customer. Most of us design sales and marketing actions around how we think, not how the customer thinks. We have this idea that we know what is right. What I will say is that most of the time we are probably wrong. Or another way of putting it, move away from thinking that you are the “expert” or the smartest person in the room. Instead move towards the thinking that the “room is the smartest person.”

When thinking about implement EDCA in sales, I believe we have to change our mindset similar to the thinking process I outlined in the blog post, Old Style Thinking of Plan – Do. It is difficult for sales teams to not only shift from PDCA to EDCA but to manage the process of EDCA in the first place. Sales need to understand that at some point the discovery that takes place in exploration must move from that act of Exploration and assimilated into operational practices. Just as we would always blame quality people of the habit of paralysis from analysis, we will often find sales either bringing in half-baked ideas or always waiting for one more piece of data or report. We need a way to start the collaborative process between customers and our organization.

In my “exploration” of this subject, I found some excellent advice from, Debroah Ancona and Henrik Bresman, authors of the book, X-teams: How to Build Teams That Lead, Innovate and Succeed. In it they said:

Other teams error by forgetting about exploration altogether and moving immediately into the implementation and action of exploitation. The drive to get things done in these cases is so intense that teams just start with the solution that first comes to mind. Management can sometimes unknowingly emphasize this “solution mindedness” by pushing the team to make tough targets quickly. The trouble here is that members may be moving quickly in the wrong direction or fail to think outside the box.

Finally, some teams never want to let go of their product. No one is interested in exportation; no one takes responsibility for easing the product out of the team and into the rest of the organization. Without this transfer of enthusiasm and ownership, team members may find their work rejected or simply ignored.

So first, teams need to organize themselves to examine the world around them, think in new directions, and consider multiple possible options (exploration). But then they must choose one direction and organize themselves for effective action and implementation (exploitation). Finally, teams need to take one last step and shift their focus again toward ensuring that their work has traction in the larger organization (exportation).

They promoted the use of Explore-Exploit-Export. Sales must find a balance between the three areas, sort of an E3DCA approach. One more tidbit from the book:

The point is that team members need to be able to shift away from an emphasis on exploration—thoroughly understanding the product, process, opportunity, or task that the team has undertaken. They need to be able to move on to exploitation—using the information from exploration to innovate and actually make their dreams and ideas into something real—and finally to exportation, in which they transfer team member expertise and enthusiasm to others who will continue the work of the team, bringing the teaEDCAm’s product into the organization and possibly the marketplace. Each of these different phases requires a different focus and hence different amounts and kinds of X-team activity.

When most people think about Lean, they view Lean only from a problem solving perspective, that 5 Why stuff. In that context, a Lean sales person would assume the role of an expert solving a problem for someone. When I apply Lean to Sales and Marketing, I view Lean as a knowledge building exercise. It is the deeper understanding of the customer business that we achieve through the methods of PDCA and EDCA.

You may be thinking why don’t we just use EDCA for the entire process. My idea is that EDCA really does define the process but  E3DCA creates an iterative loop within the process. This way we involve teams, internally and externally in a much more collaborative way.  What is happening in the world of sales is that we are on the edge (or maybe already there) of a collaborative way of selling. We no longer can just sell to a customer; we have to understand our customer’s business and our customers customer’s business. The only way that I believe possible is if we are participating at the point of use of our product or service (Lean Thinking with Service Dominant Logic) and using a process to get the message in, E3DCA.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

5 Core Sales Concepts of Lean Thinking

When introducing Lean Thinking many of us would start with the five core concepts of Lean depicted in the classic books, The Machine that Changed the World and Lean Thinking by Womack and Jones. The basic thought process goes something like this: As value is specified, value streams are identified, wasted steps are removed, and flow and pull are introduced. And we begin the process again and continue it until a state of perfection is reached in which perfect value is created with no waste.

5 Core Concepts of Lean Thinking:

  1. Identify Value
  2. Map Value Stream
  3. Create Flow
  4. Establish Pull
  5. Seek Perfection

As a sales guy, I have a hard problem identifying with these concepts. When I am thinking of value…I am thinking of what Theodore Levitt said 50 years ago…he would argue that people don’t want to buy a drill; people want a hole in the wall. When sales guys look at value, they look at how a customer uses the product or the service..the job that needs to be done. When sales people look at value streams we are looking at how a customer arrives at their point of use, their decision process.  When we think of Flow…we are thinking about how easy it is for the customer to buy, get a proposal and the reliability of my company to meet market windows. Pull…..is about agility and being adaptive…is that not the promise of Lean Operations to sales…less WIP, more agile, more flexible? Continuous Learning….the company that can learn from their customer at a faster rate than the competition is the winner today…perfection is constantly delivering value faster than your buddies down the street.


5 Sales Concepts of Lean Thinking

  1. Identify Value = Job To Be Done
  2. Map Value Stream = Customer Journey thru Use
  3. Create Flow = Rhythm
  4. Establish Pull = Adaptive, Agility
  5. Seek Perfection = Continuous Learning

The value of course depends on context. But if Lean has delivered in your organization… it has created a strategic, competitive advantage, not from the idea of Better, Faster, Cheaper. Instead, Lean should allow us to speculate, experiment, measure and iterate forward. It is a method of learning and adapting faster than your competition.

Many wonder how to put this in practice and for a template I use the five phases of Agile Project Management by Jim Highsmith. I adapted his description to a marketing tone.

Envision. Speculate. Explore. Adapt. Close.

  1. Envision: Determine your marketing vision and objectives and constraints, your community, and how your team will work together.
  2. Speculate: develop the capability and/or feature based launch to deliver on the vision.
  3. Explore: plan and deliver running tested stories in the short iteration, constantly seeking to reduce risk and uncertainty.
  4. Adapt: review the delivered results, the current situation, and the team’s performance, and adapt as necessary.
  5. Close: conclude the launch, pass along key learning, and celebrate.

Even more important, is this key point; we’re not concentrating on the flow, we are concentrating on the cycle, the rhythm. Continuous short iterations are constantly happening to improve the value of the offering. No longer can we wait for the perfect scenario. We build the scenario as an ongoing process. Customer relationships need to be as collaborative as possible. Customers then can define the capabilities needed to provide value. When that scenario can no longer be adapted or improved upon, the life of that marketing cycle is over or exhausted. This effort enables customers to view the value they need and give the opportunity for both to adapt and iterate forward. Your sales and marketing team must always be in contact with the customer and continuously asking: Is what we are doing providing value in our customer decision making or efforts to complete the job they need done?

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Evolution of the Product through Configuration Management

Jon M. Quigley PMP CTFL is a principal and founding member of Value Transformation, a product development training and cost improvement organization established in 2009. He has nearly twenty five years of product development experience, ranging from embedded hardware and software through verification and project management. Jon Quigley

Jon has won awards such as the Volvo-3P Technical Award in 2005 going on to win the 2006 Volvo Technology Award. Jon has secured seven US patents and a number of international patents. These patents range from human machine interfaces to telemetry systems and drivers aides. Jon is on the Western Carolina University Masters of Project Management Advisory Board as well as Forsyth Technical Community College Advisory Board. Jon also teaches Project Management classes at City University of Seattle via distance learning. Jon also is an expert at ITMPI (IT Metrics and Productivity Institute) giving webinars on numerous product development topics. Jon’s latest book is Configuration Management: Theory, Practice, and Application.

Download MP3 of Podcast

Business901 iTunes Store

Mobile Version

Android APP

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Evaluating a Sales or Service Control Point

In a recent podcast with Evan Leybourn (Related Podcast and Transcription: Agile Business Management), we had a discussion about Project Closure. In the past I thought it was a good thing to do. It ties into my most recent work. We have been discussing projects in general and how project management has changed. Especially from the plan-do style to the envision-speculate models. The plan-do assumes that you have acquired all the knowledge up front and can guide you to the desired outcome. The Envision-Speculate assumes you will be learning along the way and making adjustments accordingly to reach your desired outcome.

The traditional style of project closure has also changed. I grew up working projects and always understanding that every project had a beginning and an end. And in the end we had a Lesson Learned or project closure. We even used to have project stage gates or control points where we would get things back on track. This was during the days of Product Dominant Logic Thinking and transactional thinking which still exists but in the SaaS industry it is getting less common. We used to sell something hang on for dear life during the warranty period and hoped at the end we came out ahead.
Now that has changed. Car dealers make their money after the sale for example in their service departments. Rolls Royce sells aircraft engines over the lifecycle of the plane it goes on and handles all service of the product. I can go on with Kindles, mobile phones, etc. But that is not the point. Service-Dominant Logic is based on the principle that there is no value derived till the product/service is used is becoming dominant; pun intended, in our culture. Even LinkedIn and Slack credits your unused credits. Rewards cards can also be an example. What has happened is that we now view lifecycle and projects are minimized or non-existent.

Customers are now being looked at on a lifecycle basis and for good reason, especially in a SaaS company that is funded by a subscription model. When you think about project closure, it really needs to be more of a transitional step that leads to further integration between the companies versus minimizing the gains and relationships. A good transitional step that I referenced several years ago and use it quite often in SaaS type developments and on-boarding is looking through the lens of that term MoSCoW. Moscow_thumb.jpg

• M – Must Have: non-negotiable principles that every activity must comply with me in order to be considered done.
• S – Should Have: teams need to comply with these principles or justify their non-compliance.
• C – Could Have: optional principles that act as guidelines at the discretion of the team.
• W – Won’t Have: negative principles that teams should avoid.

In sales and service processes, we are always trying to evaluate the marketing funnel or in most recent terms the customer journey. How do we know when a cusotmer is ready? Are we evaluating it from a transaction-type experience or a system-type, more holistic view? Setting guidelines on how we get to the next level is imperative in a world governed by use. What is the next obstacle or target we must overcome? What is the next horizon not just for us but for the customer and for the two to co-create value together? How can we make it easier to do business with us? What is the largest risk we have? Questions like this are always popping up. However, using a consistent guideline described in the term MoSCoW may lead to more consistent results.

About: Evan Leybourn pioneered the field of Agile Business Management; applying the successful concepts and practices from the Lean and Agile movements to corporate management. You can find out more about Evan on his website, The Agile Director.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Have you done a Customer Relationship Audit?

I know your thinking that all you need is the Net Promoter Score and I will not disagree that it is an important question. However, sometimes just a good old audit and questionnaire might still have some value. You may not be able to do it all in one setting or even ask all the questions the authors of Building Better Teams: 70 Tools and Techniques for Strengthening Performance Within and Across Teams might suggest. The audit is divided into 5 parts with 15 total questions that can be rated 1 to 10 and 2 open-ended questions. My suggestions is to have not only your customers complete it, but your own salespeople and managers. The discrepancy itself might be alarming.  Pain Point

From the Book:

The process involves sitting down with your customers and identifying opportunities in five key areas:

  1.  Accessibility: How available is your team to your customers?
  2.  Responsiveness: How quickly, and with how much enthusiasm, do your team members respond to customers’ requests and inquiries?
  3.  Listening skills: How much attention does your team pay to customers’ inquiries and concerns?
  4.  Information sharing: How open is your team about sharing information with customers?
  5.  Collaboration and conflict resolution: How effective is your team at being collaborative, especially when resolving problems or conflicts?

The other part of this audit that I liked that it asked how collaborative you were doing conflict. Always a difficult thing to do. Are there other areas they are missing?

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Do We Still Need Documentation?

In this day of being adaptable and agile, should we really spend time to document everything? Sure we need some documentation done but heck — it seems like I’m creating work for myself sometimes. Is there a fine line on what goes into configuration management and how strict of a practice we keep? -jd

Jon Quiqley: I think there should be, and I think there probably is. If you are in a company who is building Website applications, and you’re all self-contained and you know where the source code is at and it’s only in one place or two places, then maybe the risks associated with that make you inclined to take one approach that might be a little streamlined. The same is true with Agile; if you’re building something that has no potential for harm and there’re not many downstream consequences in terms of build, then you might strip away some of it. But the thing is this, it adds time but if you don’t do it, it’s probably going to add a lot more.

I will share a little story that’s a little embarrassing but, fortunately, it was 25 years ago, so I learned from it and moved on. When I was first out of school, a job at an industrial applications, I was building or designing 8051 embedded type control systems. I’m writing the software, I build a little bit, and it works, and I build a little bit more, and it works. They get a little complacent because I think I’m the deal because everything I build works fine. Then I sit down and I write, write, write, write, write, write, write and build, build, build, build, build, and compile it and I compile it with no errors. Now all along, I had not changed the source file name. I build a lot, I compile it, I burn it into the target integrated circuit, and I put it into the system, and the things that were working no longer work. In fact, nothing works; not what I added, nor what was there that used to function. I think to myself, oh man, I’m in trouble. Because my source code, I kept no traceability on what rev was attached to what. I didn’t bump the revision; I just kept on writing, and the compile was the same way. The only thing I had that worked was in an integrated circuit in another one of the prototype systems. I had to take the IC out of that system, put it into a reader and the hex code out of it and turn that into the assembly language.

That was a lot of work; a lot of unnecessary work. Why? Because I chose not to keep an iteration that I knew worked separated from an iteration that I was building in terms of source code and in terms of a compiled version. In fact, I got very lucky in that I didn’t just choose to overwrite the existing memory location of that IC with this new compiled version that gave me a good compile but didn’t do anything. That’s an example of a CM failure, and I will attribute it to my youth.

Jon is next week’s Podcast guest and this is his 2nd time on the Business901 podcast. The first time can be found here Discussing Project Methods.

About: Jon M. Quigley PMP CTFL is a principal and founding member of Value Transformation, a product development training and cost improvement organization established in 2009. He has nearly twenty five years of product development experience, ranging from embedded hardware and software through verification and project management.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Outcome Realization is a Continuous Process

The outcome is really not at the end of the target. . It’s some place like in the middle because this should sustain until the end of its life cycle. -jd

Evan Leybourn:  You’re absolutely correct. The idea of an outcome is we should be able to incrementally achieve value towards that outcome. It doesn’t mean that we’re going to do one thing and achieve a 5% revenue increase, no. We’re going to do one thing after another, after another and this team or teams which are accountable for this outcome, they’re going to be constantly developing new capability, new tools, new features – whatever it happens to be, in order to deliver tools and outcome throughout the process. In a program perspective, we might call this benefits or benefits realization. But even within the context of a project, benefits realization occurs at the end of a project. It may start midway but when the project ends, the benefits are meant to be realized. Outcomes realization is really very continuous. So we may hit our 5% target, but then we go for 6% and 7%. There’s an ongoing change. There’s an ongoing improvement to the organization.

Joe Dager:  I like the sound of it. I understand it because I’m that service dominant logic type guy; value is in the use of the product. When you start looking at it from that viewpoint, it moves the customer to the center because there’s always something out there at the edges that you can build towards. Whether it’s a product or service, it takes a very disciplined company to think this way?

Evan:  Yes. We’re talking about high maturity organizations. If you’re a command and control organization, you want to know what everyone’s doing without giving them any level of autonomy that this approach is not going to work. What tends to happen in organizations that aren’t Agile, you’re a 5-person company, you know what everyone’s doing. You’re the CEO of a 50-person company; you know pretty much what everyone is doing. You get to 150, you get to 1500 people, all of a sudden, you don’t know what everyone’s doing. You can’t physically know what everyone’s doing. So what do you do? You create a process. You create an abstraction of reality that simplifies what people should be doing and you sort of expect them to roughly follow that process.

Now, that’s great because it gives you as CEO or CFO a very clear idea of what everyone is doing or should be doing, even if you don’t know specifically. But what happens in organizations that aren’t agile is that the process becomes the reality, rather than just an obstruction. Any real activity is going to have spikes and troughs in whatever that process. There are exceptions. There are workarounds. A process is only ever as good as the way of looking at that process if opportunities expose themselves. An organization that isn’t agile can’t move beyond the process.

Joe:   We limit ourselves a great deal because we’re not what I call maybe the edges and looking at the edges of projects or services because that’s where we find opportunity.

Evan:   That’s it. That’s exactly it. When you have a process, you’ve got the middle. The middle is well controlled, but that’s not where opportunities lie. And what also happens is that the middle in reality moves. You have a process that you created a year ago, it’s worked fine, but the market has moved on. Suddenly it’s now mobile-centric rather than web pages. If you’ve got processes around a particular way of working and the market evolves, then what you would consider as being edge is actually the norm, is actually the middle ground and you actually start to lose market share because you cannot compete.

Related Podcast and Transcription: Agile Business Management

About: Evan Leybourn pioneered the field of Agile Business Management; applying the successful concepts and practices from the Lean and Agile movements to corporate management. He keeps busy as a senior IT executive, business management consultant, non-executive director, conference speaker, internationally published author and father.  You can find our more about Evan on his website, The Agile Director.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)