Not knowing what I was getting into (a common state lately), I joined some former colleagues to catch up on their new venture. They asked me how I would go about designing a software team for their new pivot. They were going from a B2C product to a B2B (B2B2C) variant based on their recent customer discovery process.

I allowed as how I couldn’t think through the question without standing at a white board so we found the nearest vacant room and a few white board pens and started in.

As they were in Silicon Valley, I started by paying homage to the latest craze of hacker, hustler, designer and visionary that is making the rounds. But with several twists.

I started by drawing a draft of the diagram below:

Then I realized that I was once again violating the “experience first, make meaning second” mantra. So I put my magic marker down and told a story.

After we’d gotten good and cash flow positive at Attenex, we were looking for additional markets. One of the many reasons I was interested in creating Attenex Patterns was so that I could have a personal version to make meaning out of my 8TB of digital detritus on my desktop computer. While we knew that we couldn’t do a stripped down version of our enterprise level product, we didn’t know what were the necessary and sufficient features for a Personal Patterns.

So I pulled in my lead architect to spend a month researching and building a personal patterns prototype. Eric was the architect and UX designer. I filled the roles of visionary, UX researcher and hustler. We made good progress in three weeks and a part of my hustler role was talking about and demoing the prototype to anyone I could grab (trying to find a lead customer). Everyone nodded and patted us on the proverbial heads and said “that’s nice” but there was no energy in the engagements.

So we went back to the drawing board and I went and did a little user research with Marty Smith (one of the lead customers for our Attenex Structure product), a contracts and Intellectual Property attorney at Preston Gates. Not really knowing what I was looking for, I asked Marty if I could just sit and observe him working on contracts for a couple of hours.

One of the lessons I learned at the Institute of Design in Chicago is that observing people in the wild (their actual work or living environment) is far better than trying to interview them. People make stuff up (mostly because they don’t want to appear stupid) when you interview them and most of the time they don’t really understand what they actually do (tacit knowledge). However, they are incredibly “articulate” when you can just observe them in their natural work habitat.

Marty was working on his third draft of a licensing contract for a very large software company headquartered in our area. There was a lot of client discussion around a patent indemnity clause. He knew that he’d had to rework that clause for a couple of different clients in his previous ten years, but he couldn’t remember which clients nor which parties the contracts were for.

Marty’s primary tools are Microsoft Word and Outlook/Exchange. He organizes his file foldering systems (both on the hard drive and in Outlook Exchange) by client and then by year and then by the company name of who a contract was with. One giant hierarchical mess. He could have used a primitive Boolean search engine (but his law firm IT group wouldn’t allow such a thing – corporate security and all). Even if he’d had a search capability, by searching for “patent indemnity” he would have gotten 1000s of hits.

So I watched for thirty minutes as he walked the folder hierarchy, trying to use the client folder names and the contracting party names to jog his memory for one of the three or four contracts he’d modified in the past. He’d drill down through folder after folder; select a contract; scan through the contract in MS Word to see if there even was a patent indemnity clause; find nothing; and then go back to the folder hierarchy. No joy. So after thirty minutes, he gave up and went back to crafting a new clause.

I knew I was seeing something important here, but didn’t know quite what. So I asked a few business model questions.

Skip: How many times a week does this happen to you where you can’t find a clause you are looking for?

Marty: 3-4 times a week.

Skip: How many times a week does it happen to the other 20 IP attorneys in the firm?

Marty: Probably the same amount for each of us. And we never find what we are looking for so we have to draft from scratch. We try for a while, but never find anything.

My back of the envelope business calculation was the extra cost to clients of $500 per hour * 20 attorneys * 2 hours (search plus redrafting time) * 3 times per week = $60,000 per year. In this one law firm we had $60,000 per year of savings for what I was thinking we might price at $20 per seat. Oops, missed the value equation on this one.

I bounced down the stairs to share my findings with Eric. I described what I’d seen (unfortunately because Marty was doing client legal work I couldn’t use video ethnography to record and analyze his interactions). We realized that the difference that would make a difference was if Marty could do clause level searching rather than try and guess at a couple of keywords that might be needed.

We put some straw designs together on the whiteboard and then I left Eric to do a prototype. After a few iterations, Eric worked his brilliance and came up with the following:

On the bottom left, the user selects a range of text to use as the search string. The selected text could be a couple of sentences, a paragraph or pages of text. The text is then copied into the search box (top of slide) and the text is treated as if it were a series of “OR” statements. Some 2381 documents were returned. That is clearly too many to look at. So either the slider bar for “Contains” is moved to the right or the “Proximity slider bar” is moved to the right until a more limited number of documents is identified (in the example 42 documents are returned). [NOTE: For those of you interested in the gory details of the search technique you can look at the Attenuated Search patent application.]

Once you get to a reasonable number of documents to look at you can display them with one of the standard visual analytics view of Attenex patterns (semantic network view, social network view, or timeline view).

Well, the fun was just starting. I went into my hustler persona and took the opportunity while we were interviewing the CIO at Bell South for a board position to demo the new prototype. I was unprepared for the result. He grabbed my laptop out of my hand and said “I’ll take it back with me.” Momentarily defaulting to my designer role, I objected “But you can’t; it’s just a prototype.” A tug of war with my poor laptop ensued as we both chuckled.

Quickly going back to my hustler persona to see if I could glean some more marketing data, I asked the CIO how much he’d pay if the prototype were indeed a product. He thought for a few seconds and said “I’d want this for the top 100 executives and managers (and our assistants) at Bell South, so I think an enterprise license of $300,000 per year would be appropriate.”

With just the addition of the “clause level” searching, we’d gone from no interest to a “got to have” application that senior managers were willing to pay quite a bit for.

While Eric and I were lucky enough to have the skills to play all four roles of hacker, hustler, designer and visionary, most teams will need three to four professionals in these roles.

What gets missed with the above story is a really critical team member – the lead customer. Most people assume that the UX person (designer and researcher) can be the customer surrogate. However, I’ve found that it is crucially important to view the lead customer as a member of the team and invite them inside the product development bubble. The key to having the lead customer as a team member is to be able to regularly visit the customer’s work environment. Their work site is where the observation action is.

Let’s look at the four key roles of the ideal software product development team:

• Visionary – the visionary sees the opportunity and imagines what technology is capable of solving the customer need. In an ideal world, the visionary sees not just a “nice to have” but a “got to have” solution and a business model that makes money quickly. A good visionary will have a big dose of hustler in them – the ability to “engineer exchanges to separate customers from their money (time/attention) willingly by creating, communicating and delivering unique value” (thank you Dan Turner for this definition). As Dan Pink shows in To Sell is Human, the hustling skills can be learned (and most of us are tacitly already “selling” most of our time).
• Architect – builds the prototype and foundation for the product. While the term of the moment is “hacker,” I prefer someone that can go beyond prototyping and design at scale. They are able to translate the visionary opportunity and designer wireframes into something that works. An ideal software architect will build at hacker speed and think/architect for scale.
• User Experience Designer – observes customers and translates the observations into human computer interaction designs and thinks more broadly about the full user experience design. The UX researcher needs to exhibit “beginner mind” and be optimally ignorant while observing customers “in the wild” and in their natural work habitat. A key role of the UX researcher is to See Organizations.
• Lead Customer – the ideal customer is the manager who has the direct need and the budgetary authority to buy your product or services. They should have the time, expertise and commitment to see the project through. The “got to have” need has to have one or more (preferably all) the characteristics of increases efficiency, increases effectiveness, increases revenue, and decreases expenses.

It is the responsibility of the Visionary/Hustler to find the lead customer. They need to go beyond seeing the opportunity and find the customer who can help them create the solution. Once they get the lead customer working with the architect and the UX Designer, the visionary/hustler needs to identify the business model that will not only grow their own business but help the customer grow their business (see Growth Partners).

To help identify good opportunities, the visionary uses a form of “backward chaining” by finding workflows that have a clear valued outcome and then working backwards to the starting point. A really good opportunity will have a decision point which leads to high value and/or a high risk outcome. Inserting a product into a high value or high risk workflow allows you the opportunity for value based pricing. The realization that the eDiscovery market was very high risk and high value allowed us to build a value priced solution with Attenex Patterns.

Through hard won experience, I’ve found that you can’t just trust the architect and UX designer to stay focused on what is necessary. They drift. No matter how experienced they are, they drift. The visionary needs to check constantly on the progress of the product team. The easiest way is with the daily demo (not the agile daily check-in where the developers talk past each other, but an actual demo of what exists). I describe the daily demo process in Advice to a Non-Technical CEO of a Software Start-up. An even better way is to bring the lead customer to these daily demos on a weekly basis.

With a good team and good process (daily demo), you are ready to race to a Minimum Viable Product (not minimally valued product as newbies misstate) in parallel with your customer discovery process. Of course someone needs to manage this process and balance the Four Developments. That’s fodder for a future post.

For more information on this human centered product design process check out the following resources:

• IDEO Human Centered Design Toolkit
• Running Lean by Ash Maurya – a terrific synthesis of the Lean Startup method of Eric Ries, the customer discovery process of Steve Blank, and Business Model Generation of Alexander Osterwalder
• To Sell is Human by Dan Pink
• 101 Design Methods: A Structured Approach for Driving Innovation in Your Organization by Vijay Kumar
• Communicating The New: Methods to Shape and Accelerate Innovation by Kim Erwin
• Ten Types of Innovation: The Discipline of Building Breakthroughs by Larry Keeley

For a humorous look at the wonderful world of innovation and new ventures, checkout Fl!p and the gang at Fl!p Comics.