Home › matthart

It’s been about 4 years since we started the project that became echominder. We weren’t a development team at the time, just design, so it took a reorg and a charter change before we could go for it. By then, quite a few competitors had been in the market for at least a few months.

Another reorg and our focus again has shifted to supporting the innovations of business unit folks, and we haven’t been able to find anyone at Intuit who is interested in taking on future development of echominder (although we’re keeping some of the underlying technology around in support of some projects). So we’ve made the decision to sunset the offering. It’s personally tough for me write this, as probably no one has as much emotional energy invested in echominder, except maybe Anna, our designer and the iLab member who was on the original investigation team. But it is the right decision, as we need to focus our resources on helping the greater Intuit innovation efforts. Here’s how it’s going to happen: First, there will be some minor changes to the website. We’ll disable new account signups, put some messaging on the front page and the account page regarding the sunset. There will be a link on the account page where members can download a call archive. Members will get an email talking about the sunset and pointing them to some alternate services such as Jott, Pinger and Braincast. The call-in IVR will change slightly to indicate the date that it will no longer be available. 3 days prior to the sunset, no more calls will be accepted - but any scheduled calls will go out. On the day of the sunset, the echominder.com website will redirect to Intuit Labs. 1 month after the sunset, the phone number will be discontinued 6 months after the sunset, all archived messages and any other private information will be deleted from databases and backups.

We’re keeping the files around for 6 months in case anyone suddenly needs their messages. A big thanks goes out to all of echominder’s users, especially Matt F, Adam B, Evan S and Lisa R. Thanks for all of the feedback, comments and suggestions. Check out the other services that I mentioned above, and check out other new offerings from Intuit Labs.

January 8 2009, 3:57pm | Comments »

I posted to intuitlabs.com

Customer Stories: critical thinking mindset part 1/4

http://intuitlabs.com/blog/archive/2009/01/customer-stories-critical-thinking-mindset-part-14/

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.