Critical thinking is, well, critical to the success of a project. You need people who can poke holes in your arguments, help you weed out unnecessary features, keep you focusing on the right thing. Startups are often good at this - they have to be in order to survive. But when you get into a larger company, survival is a different path, different tools, different skills. So it’s no surprise that when it comes to critical thinking in many projects, e.g. answering questions like “how would that customer use this” and “why do their existing solutions fail”, people often forget to take the time to ask those questions. There are many approaches to helping teams think critically, e.g. the 5 why’s, d4D, root cause analysis. But I haven’t come across any truly successful ways of teaching or infusing the mindset that critical thinkers seem to come by naturally. So I’m going to run an experiment by you. I’ve thought of a path, and I hope you’ll tell me whether or not it works for you. Does this and the subsequent blog posts give you any new insights, any new techniques… does it give you a new mindset?
The Critical Thinking Path: Customer Stories, Customer Requirements, Use Cases, Functional/Feature Requirements ————————————————— Part 1: Customer Stories First, my definition of a customer story is, well, a REAL customer story. Not a theoretical customer, not a target customer, not how a customer might use your offering. If you’ve never been on a customer visit, then I’m sorry, but you can’t tell me a customer story. So when I ask for one, just say you don’t have one - no making it up. When you visit customers, you see the context of their problems. Example: The inventory problem of knowing “what’s in stock” - from an optical parts manufacturing firm I visited. What they told us is that they take orders, print it, put it in a bin, add the parts to the bin, put it in the assembly area, it gets assembled, bin goes in a separate area, quality checked, shipped, order goes back to the office where it’s invoiced. They even show us all the bits in the process, shelves with bins, etc… Sounds like a simple “standard quantity on hand, on order, sold, etc…” problem. They just need a report, right? Charts and graphs that show how much they sold, automatic reorders. Maybe they just aren’t getting the data entered quickly enough… maybe we could automatically update based on a shipping notification of some kind… So now let’s take a walk through the warehouse. What we SEE while walking around is a little red sticker on a bin. Actually, there are red stickers on more than half of the bins. “What are the red stickers for?” Oh, well, we just got an order from a big customer, so we took parts from a smaller customer order so that we can satisfy our big customer, even though it’s a smaller order. The red sticker means it’s missing parts. Whoosh… that’s the sound of the quantity on [fill in the blank] ideas going out the door… And there are dozens of other examples from visits: the bag maker where four jobs in up to 10 stages can’t be known unless you walk the floor and peek under the piles, or that extra service truck where items are swapped in the field, so that now the new service rep doesn’t have a solder torch or even a hose for draining the pipes. Customer stories help bring out the exceptions. When everything goes according to “plan” in a business, there are few, if any, pains. Orders come in, service and products go out, customers pay, and the power stays on. Natural workflows. But where we can help the most is in the exceptions, and you can’t learn what those are, or how your offering will fit into the existing processes of a business, unless you go out and visit places. Be curious. Always ask about the red sticker. Have lots of interesting stories to tell - and most importantly: BE ABLE TO ANSWER ANY “Why does your application do this?” QUESTION WITH A CUSTOMER STORY! ————————————————— The Critical Thinking Path: Customer Stories, Customer Requirements, Use Cases, Functional/Feature Requirements When you have customer stories, you can always travel up the path from your application, derived from functional requirements that implement specific use cases. Those use cases are based on customer requirements that come from customer stories. Never implement ANYTHING without a real customer story to explain WHY it is needed and so that you can verify HOW it will be used.