In NUvention Web, we have students build a list of product hypotheses (product ideas) and start talking with customers. Based on my experience in building new products and in teaching software engineering and NUvention web, after you have the initial product idea, I recommend the following process to validate your concept and initial value proposition before building an MVP. The research also helps flesh out development of a product’s business model canvas. For business model canvas, I’ll reference what we are using in NUvention 2012, Ash Maurya’s excellent RunningLean. Ash has put together a variant of Osterwalder’s canvas focused on some of the key elements facing a web based business. This discussion on product insight actually comes out of an email exchange with Ash and discussions with the NUvention Faculty Team (Chris Riesbeck, & Michael Marasco) While the process I’m describing is primarily geared toward new products being developed at a new company; they work equally well on established products or larger teams with a few modifications. My recommendation is to validate the product hypothesis by having the product and customer development team do the following three steps:
- Have open ended discussions with “experts” in the target customer.
- Conduct a· 360 degree competitive analysis (something I will elaborate on in a future post; but think of it as building on the Michael Porter 5 forces framework)
- Do Ethnographic research, using a technique like Contextual Design, on the customer segment and its related actors to discover latent needs and very specific opportunities
This post will primarily elaborate on the third; and I will have a brief discussion of the first, which we do as a pre-assignment in NUvention web.
Ethnographic research has its basis in anthropology and is widely used in product design today. It borrows many anthropological techniques. In fact, when I worked at Microsoft, Donna Flynn, who managed user research in the Windows Mobile design group when I was there, is a PhD in anthropology (from Northwestern!) and used the techniques extensively. The method I prefer is based on another PhD in anthropology’s work—Karen Holtzblatt—who started to apply these techniques while she was working at Digital Equipment Corporation in the 80’s. Holtzblatt has published many articles, and has two books on using an ethnographic research model she calls contextual design:
- Rapid Contextual Design: A How-to Guide to Key Techniques for User-Centered Design (Interactive Technologies)
I’ll refer to this as “Rapid” below.
- Contextual Design: Defining Customer Centered Systems I’ll Refer to this as the “CD Book” below and the general technique as “CD”.
We use the rapid book in our class; but the CD book is more complete. Additionally, we have had LUXr (Janice Fraser) do a workshop for the class last year. In a presentation she did she had a useful pruning of customer interview techniques see http://www.slideshare.net/clevergirl/luxr-oneday-workshop starting at about slide 40; and look especially at the slides starting with 55. We haven’t used these in NUvention web; but as we evolve the class, I’m thinking about the best way to pull all of these together.
A bunch of things are super useful from rapid CD:
- Watching work to infer needs vs. asking a user a specific leaded question or showing them the product. Users are generally pretty bad at giving a product builder a useful critique of something. If you watch them work, you can usually see where they REALLY need help and what you can do for them (i.e. latent need). CD interviews have you watch the end user do related stuff and you take notes. For example, in class this year we used as an example a team that is looking at software for food trucks. This team was able to look at all the activities of the order process from the person in the truck’s point of view, as well as the customer’s point of view. They also learned a lot of these trucks have a coordinator who helps with social media and doing other tasks. They could enumerate those tasks to understand which ones would be valuable to automate; as well as what the orders needed. The technique has you do a two person de-brief; which is good because the person who wasn’t on the interview can ask a bunch of questions to get data.
- When you do this kind of interview, in addition to the roles of the different actors, you see a bunch of core processes (in our food truck example: taking and fulfilling a pre-order, managing the credit card process) as well as important adjacencies (finding a legal place to park or at least one where you can avoid the cops!). If you see the order taking at a few trucks for example, you can abstract the sequence of tasks into something you can automate or at least come up with potentially fruitful feature ideas (location services to let you know whether or not you are within 200 feet of a restaurant–a legal requirement for food trucks in Chicago).
In a full CD (models in the CD book not the Rapid book) other things can be very helpful in the early going. There is a model called “culture” that helps you understand influences relative to your product proposal. While the “culture” model rarely results in specific features, it helps teams understand the environment dynamics that can affect your business model (who are the influencers on a decision? How is the budget determined around a particular product area? What are the barriers to getting a new solution adopted? For example, in the food truck case, there is the influence of local regulations on their industry; as well as parking. From the customer point of view, in an office, it turns out there is usually one person who knows about the food trucks (this would be at Microsoft what we would call an “Influential End User” or is now often called a Net Recommender. There is also one called flow where you look at information exchanged between people in various roles. This can be very good for collaboration oriented services. For example, one of our teams is looking at software to help assist producers and directors in running a shoot for movie, commercials, or TV. A flow model would let you know how and what info they exchange and build an abstraction across a few interviews (8 to 10 is the sample generally needed).
We currently have teams build an “affinity” which is a collection of random facts across interview organized by subject (each interview generates between 50 to 100 factoids) but the minutiae is not that interesting; it’s the abstraction that’s interesting and that takes a fair amount of effort to build. We’re not sure how useful that really is in the long run, other than getting a product team on the same page about the customer, and helping build a persona (a persona is the next level of detail for a customer segment, i.e. how do you characterize a particular person with the segment? Alan Cooper is the guy credited with inventing them, but a quick google showed this to be the best overview link http://www.steptwo.com.au/papers/kmc_personas/index.html What are their average demographics relative to the product (e.g. in an email product, how much email do they have), what are their top tasks, what are their constraints. We used personas a lot when I was at Microsoft. I found they were often abused; though Donna’s team in tandem with the product team on Windows Mobile did some excellent in depth ones that were tightly linked to an extensive quantitative segmentation our product managers did.
In addition to personas; we have the students do storyboards. A storyboard is a task flow that includes “out of system” things like user intent (e.g. what was the motivation that led the user to the scenario in the product) as well as system behavior (e.g. what data needs to be entered at each phase). It’s rough sketched, which I think is the right level of detail at this phase of the project; but it does include some functional detail about the construction of the UI. It’s not a complete functional description, and while we don’t do a complete functional description in NUvention web, I’ll talk about the kinds of functional description I find useful.
I’ve noticed an issue with contextual design and lately rapid contextual design as we’ve used it in the class I will caveat here. The issue I think we have with the CD processis that it has a lot of relatively formal models that are of varying usefulness. The big thing in our class that people struggle with is getting to a useful and focused scenario to build and test for their first MVP, that’s grounded in enough research that its not a complete myth to reduce the total number of iterations. Rapid provides a good way of structuring the data from the interviews; but the goal should be for teams to focus on what they need from the technique, rather than technique for its own sake.
Other problems are these techniques tend to find “pains” as opposed to “joys”. We had Ben Huh (cheezburger.com ) talk in NUvention web a few weeks ago; and failblog and icanhascheezburger were all about creating joy and engagement; not really around alleviating a pain (other than distraction from a busy and mundane world). There, it was really the quantitative growth of both memes that the internet enabled that was the key website; and that people would think captioning cat pictures was fun. I think CD CAN help find where a disruptive technology can intervene; but they won’t help you pick which technology; just figure out what pain to shoot the technology at.
The other challenge that sometimes comes up is the Steve Jobs defense of not doing research. It quotes Steve Jobs, as he talked about in this fortune magazine interview. The defense goes that steve didn’t do market research; so why should I do it. Well, I will quote another UI great, Don Norman. In our first year, he told our class “Steve Jobs is a genius. He doesn’t need user centered design. Most of us aren’t Steve Jobs, we need the method of user centered design. The other reality, even in the interview, is you see Jobs talking about critical examination of products in the category (cell phones in this case). This is part of something I call 360 degree competitive analysis. CD even has a way of doing this—there is a technique called a “reverse user environment” that’s about deconstructing a product to its core UI principals. It also has one for looking at manual processes and abstracting them—consolidated artifact analysis. My experience is very talented UI folks can intuitively do this—the way some people can do 3 digit multiplication in their head—but the rest of us need to learn how to carry the 1 and offset by 10 and add for the 10’s and 100’s place.
; and this year it’s a required text. We have to rationalize Running Leans version of the canvas with Osterwald; but that was a price we thought worth paying.
as “staged”. In the staged model, the team runs an iteration called a milestone lasting about 3 months, divided nearly equally between coding/unit testing and integration/system test. I draw some comparisons to some of the things Fred Brooks describes in 
in terms of stabilization time and project scale. 
.
. The idea is certain metaphors dominate user interaction; even if they aren’t the simplest. A great example is the