The Define Phase is well documented in the Plan of PDCA, Define of DMAIC, Discovery of Appreciative Inquiry or even the Dream of Disney. In the Explore stage of EDCA what makes this phase different?
Paraphrased from Nigel Cross’s book, Engineering Design Methods: Strategies for Product Design:
Designers tend to use conjectures about solution concepts as the means of developing their understanding of the problem. Designers impose a primary generator and generate early solution concepts. This is used to base a tightly restricted set of constraints or solution possibilities. The problem cannot be fully understood in isolation from the solution, so solution conjectures should be used as a means to understand and explore the problem formulation. As the architect, Richard MacCormac has said, “What you need to know about the problem only becomes apparent as you’re trying to solve it.”
Solution-focused strategies are perhaps the best way of tackling service problems which are by nature ill-defined problems. The major hindrance to this type of thinking is found in becoming fixated on a particular early solution concept and an unwillingness to discard the concept. Instead the make minor improvements rather than discard the work and stat with a fresh idea. Another problem is going too much in depth versus staying at a minimum level to continue the process. You should look to having a “reflective conversation with the situation,” so wonderfully said by Schon.
Cross added these steps for the solution focused process:
- Clarify requirements by asking sets of related questions which focus on problem structure.
- Actively searched for information and critically check given requirements.
- Summarize information on the problem formulation into requirement and partially prioritize them.
- Do not suppress first solution ideas, hold on to them and return to them to clarify the problem rather than pursuing them in depth.
- Detach themselves during conceptual design stages from fixation on early solution concepts.
- Produce variants but limited the production and overview periodically assessing and evaluating in order to reduce the number of possible variants.
Another part of the process, especially used by designers and architects is the act of sketching. They have a tendency through sketching to handle different levels of detail shifting from overall concept to detailed aspect practically simultaneously. Sketching permits tentative solutions to be explored and investigated and the typical hierarchy steps of problem-solving analysis are prevented.
Is it all about empathy?
Amazon review: Having read many a dry but interesting psychology book, this author had a way to make the subject matter come alive. I can see where this would be required reading in many a (fortunate) psychology class, however better yet, this Situations Matter calls for us to be better people.
* We need to realize people are not always what they seem in one situation.
* We need to realize that even in groups, we have the responsibility to help and not expect the crowd to do so.
* If something seems wrong to us, we should not let the crowd or the authority figures dictate our behavior.
* Women and Men are more similar than different and should not be so categorized, or limited in our expectations.
* Sometimes by acknowledging differences between groups, we find freedom to move on, or at least recognition of our own reactions
* Last but not least, observe and don’t assume and in being more considerate, we can live together more harmoniously.
In service design, think of exploring a customer journey map allowing for multiple paths to be explored. For example think of a user scenario that might help you identify multiple paths. A few ideas on constructing one:
- Practice being a user. A good exercise is to use de Bono’s Six Thinking Hats and apply that thinking taking different user points of views.
- Observe users in action. Insure you are watching both novices and experience people.
- Question users about their experience. You can use a variety of methods that are formal, unstructured and even focused groups.
- Create user personas and scenarios. A persona is about a well-defined but hypothetical user and a scenario is a storyline about the use of a product or service.
Remember the Bain Study that said: “80% of Companies believe they deliver a Superior Service, only 8% of Customers agree.” Don’t we need a breakthrough strategy to improve our service? The define mode is critical to your success, you must create a specific compelling problem statement. Many people believe that developing a specific problem statement will limit your efforts, your creativity. This has proven to be false and is well documented by the Heath Brothers in the landmark book, Made to Stick: Why Some Ideas Survive and Others Die.
In a podcast I had with Chad Smith of the Constraints Management Group I asked the question, “Why did McGraw-Hill come to Carol and him to write the new edition of Orlickys Materials Requirements Planning 3/E
The problem is that the market really doesn’t know how bad the problem is. They don’t really understand why MRP is failing. What the real deficiencies are of MRP. That led us to write a white paper. We wrote a white paper in spring of 2008. We submitted it just on a whim to the APICS organization saying, here’s something that we’ve written. Are you interested?
We got an immediate response back from APICS saying can you condense this a little bit for our magazine? We said sure, we’ll do that. We condensed it and little did we know that it turned out being the cover story for the July/August 2008 edition of the APICS Magazine.
That intrigued us. It told us, wait a minute, there’s something people are resonating with what we’re writing here. APICS sponsored a webinar a couple of weeks later on a topic and 250 companies signed?up. Three weeks later Carol spoke at the APICS conference in Kansas City and there were 350 ? 400 people in the room. There was standing room only.
We got pretty excited because what people told us was the reason why they got so interested in this was because of our depiction of the problem and the fact that the way we described the problem was exactly what they were experiencing. There just didn’t seem to be a fix out there in the industry.
We spent the last couple of years articulating this. We were asked to write a chapter for another book that McGraw-Hill was publishing. Based upon the strength of that chapter, the editors of that book kicked it up to McGraw-Hill and said you really need to take a look at this. This deserves a whole book.
We went round and round with McGraw-Hill a little bit because McGraw-Hill was a little bit worried that people had never really heard of this concept, these new concepts. I agreed the book might not sell well because nobody’s really heard of this new approach to MRP.
They came back and said; “We have this Orlicky book that needs to be updated. Would you like to do that?”
From Carol and my perspective we were like, wow, yes, absolutely. That’s a perfect scenario for us. It allows our message to get into the typical MRP user and even buyer of software so that we can really demonstrate what the problem is and what the direction of the solution is. How we can augment or how we can amend the MRP and ERP for the new century.
What did Carol and Chad do that was different? Their description of the problem was exactly what customers were experiencing. You can spend countless hours on branding, messaging and every other marketing tactic under the sun but do we ever articulate the problem are customers and prospects are having – perfectly?
Lewis Mumford (1895-1990) was an American Architecture and Literary critic, as well as Sociologist and Philosopher. I often attribute a particular quote to Mumford, though I can’t seem to locate the source. When asked where to put a sidewalk, Mumford responds: “See where the people walk and then pave their path.”
How many times have you seen two sidewalks intersecting at 90 degree angles, with worn grass cutting the corners? There’s a fine line between executing on your vision and listening to your customers. Consider Mumford’s quote, thinking of the sidewalk as the “vision” and the path as “customer needs.”
Describe the exact problem the customer is having.
Do not proceed without crafting a problem statement. The work in doing it is generating a problem statement different than the ones we are accustomed too. As Tina Seelig’s stated in the video on the EDCA Intro page, we have grown up answering questions such as 5 + 5 = ? versus being asked ? + ? = 10. There are several schools of thought on how to accomplish this:
- A3 thinking which is the basic Lean Problem Solving Method.
- Appreciative Inquiry or a strength based approach.
- Shainin Method where you view desired outcomes and work backwards.
- Design Thinking type of approach based on empathetic findings.
There is not a right or wrong answer. In fact, you could separate your team and have them attack the problem statement from each direction. I propose that you choose at least one of them fits the culture of your company(Family – Personal Kanban). Take your proposed problem and craft several problem statements. Don’t forget to view these stories from a Service Dominant Logic thinking perspective. You may like to create user stories that have an outlook based on the three values of functional, social and emotional.
The INVEST acronym from the User Stories Applied: For Agile Software Development
- Independent: The story should not carry with it dependencies, which can lead to estimating problems. Instead the story should be completely independent so that it can be worked on without pulling in a set of other stories.
- Negotiable: Stories should have room to negotiate – they are a starting point, not a contract.
- Valuable: The story should communicate the value to a user or customer, not to the developer. The story should define not only what a user can do, but what value the user gets from the implemented story. If there is no value, cut the story.
- Estimateable: You need to be able to estimate the amount of work required to implement the story. If it is too big and too daunting (an epic), break it up into smaller stories.
- Small: Similar to the previous, stories need to be small. Large stories are too complex to manage, and are typically more than one story compounded together.
- Testable: The implementation of the story needs to be testable. Define the tests that can be performed to validate the story was correctly implemented.
From a service perspective, you could develop user stories for many of your projects. For an example, consider developing a direct mail piece for a home roofing contractor: Using the standard outline for developing a user story: “As a [end user role], I want [the desire] so that [the rationale]. The user story may go something like this: As a roofing contractor, I would like to develop a 4-part mailing program targeting subdivisions of 20 to 24 year old homes.
- Using INVEST, I could look at this user story and conclude:
- Independent: Yes it is very independent.
- Negotiable: I think it is negotiable from the standpoint that you might be able to yse a 3 or 5 part or make some recommendations after initial testing.
- Valuable: I think presently it is rather weak in that area.
- Estimable: Time frames are very easily estimated.
- Small: The actual story is very small and well-defined.
- Testable: I think like most direct mail pieces, unless under a time constraint sample pieces could be sent and feedback given as additional pieces are developed and modified from the feedback.
As mentioned before, user stories can be written from other perspectives. Using this example, try writing it from a few of the other perspectives mentioned. Even try writing it from the home owner’s perspective (the end user). What could we create using our standard outline: “As a [end user role], I want [the desire] so that [the rationale]. As a homeowner, I would like information on the telltale signs that my roof needs inspected. With this approach, you can see not only the need for supplying relevant content that is of value to the consumer but this story will strengthen your message. As you develop the piece, you may even find more content and/or a more targeted message.
Explore is where you take your empathy findings and turn them into compelling needs and insights. In service design evolving to an answer though customer interaction is one of the best methods of problem solving. You may have to accept a solution that may not be the best in your mind. But an idea that can be implemented is much better than one that cannot be. However, do not lose sight of your overall goal: To profitable create customer experiences that are so compelling that their loyalty becomes assured.
Create user stories for your service/product (Personal Kanban effort) using either the layouts below or a few that you may create. Write a bunch!
User Storycard examples:
- As a ____________________ (type of user), I want to _________________ (need), so that I can ________________ (reason)
- In order to _______________ (value), as a ____________________ (customer), I want ___________________ (some feature).
- In my world _______________ (place), I ____________________ (customer), need a way to ___________________ (need).
- While a ___________________ (person) is in __________________ (place), they need to find/meet with a ____________ (person)
because_________ (motivation).
- A _____________________________ (person) who is trying ______________________ (motivation) at _______________ (place) must prepare for
__________________ (activity), which they will have to do in _________________ (time).
- ______________________________, ____________________________________________, __________________________________________.
The challenge to the user story is that they should be written from different perspectives. Don’t only think from a customer perspective but take a deeper dive. Think of a several different positions (B2B), CEO, CFO, Team Leader, Technical Person. Or, in a consumer field think of the husband, wife, child. This frames the context of the story. What typically becomes apparent is that certain users are more likely to enjoy the experience that your organization can deliver. If you take it a step further and are able to create a story from actual users or potential users, you gain valuable knowledge in your design process before you start.
Value Proposition:
When most organizations think about their value proposition, they think about the tangible benefits that the organization offers or how much better they are in a certain area versus the competition. It might even include their history, technical expertise, latest technology, commitment to customers, etc.
In the book, Strategy from the Outside In: Profiting from Customer Value the authors describe their variation of a value proposition:
We prefer a third variant that we see in use among customer value leaders. A customer value leader bases its value proposition on a resonating theme – a few elements where the firm is distinctly better than the competition that really to a target market. An effective value proposition offers superior performance, price or relational value and communicates that value in a way that shows that it has a deep appreciation of the customer’s value priorities. The choice of value proposition is also the choice of target customer segment – and vice versa
This variation though more customer centric stops short of describing the experience the customer will have with the company. One of the interesting things about Agile Project Management is that you start with creating a user story. Work is expressed in the backlog as user stories. A team may write its user stories in a number of ways as long as they are written from the perspective of the end user. Put another way, team members are encouraged to think of their work from the perspective of who will use it, hence “user” story.
In building a value proposition, how many times do you start with a customer/prospect telling you how they use or will use the product or service? I know we interview people or perform won/loss analysis, but I want to go an additional step. What if we would paint the picture of how a user experiences your product or service? If we would take the time to determine that reaction, would we not create a better value proposition?
I think it might be interesting to define your entire business and your target business through customer experiences. Actually, cataloging the various experiences a customer will have with an organization is a needed exercise to enhance the value of the total experience for its customers.
Interesting Side Note: Joseph B. Pine II and James H. Gilmore, in their book The Experience Economy: Work Is Theater & Every Business a Stage
- If you charge for Stuff, then you are in the commodity business.
- If you charge for tangible things, then you are in the goods business.
- If you charge for the activities you execute, then you are in the service business.
- If you charge for the time customers spend with you, then you are in the experience business.
- If you charge for the demonstrated outcome the customer achieves, then and only then are you in the transformation business