Pages

Google+

Thursday, September 5, 2013

Zero To Product: Customer Development, Modeling Timelines & Shared Problems

This is part 3 of a retrospective on vizipres: A product I began and worked on for a few months. 
part 1, part 2, part 3, part 4, part 5, part 6, part 7


Listen & Stay Focused


To recap, here's where I am:


Next, it was time to start talking with customers to learn and validate my hypotheses. Armed with that information, I would then build some models so I could start thinking about designing the UX. Even though by the time I started vizipres I had conducted countless customer interviews for other products, I did make some mistakes with my interviews for vizipres. The mistakes are generally more interesting, so I'll lead with that.

Bad (Or At Least Medicore) Questions


Before starting an interview, I made sure I had a list of questions to ask. While I don't ask every question I have written down, I do use them as a reference. I prefer interviews to be free-flowing as much as possible. 

For vizipres, I came up with these questions to work with:
On the surface these questions seem like a good idea, but looking back I would do it differently. The first question, How do you share information now?, is a good example of how a question and answer can, at best, be mediocre and, at worst, a waste of time.

When I would ask 'How are you sharing information now' customers would either be a bit confused, requiring me to explain further by giving examples such as:

  • Status within the organization
  • Sales numbers or other metric data
  • Documentation

...or they would feel they understood the question and then would launch into a very high level description of how their IT infrastructure works - which isn't what I was looking for. I found the two biggest problems with this question is that:
  • It's not specific enough, requiring me to give further examples
  • It can mean very different things to different people
The biggest problem with a question not being specific enough is that I have to explain it more. The problem with explaining it more is that I start talking a lot and putting scenarios and thoughts into the customer's brain - basically priming them. I don't want anything like priming because they are more likely to give me the answers they think I want.

The rest of the questions were also not very helpful to me. Sure I was getting information and validating some of my hypotheses but they weren't gold. I also ran into the problem of gathering a lot of unshared problems between customers. I didn't know this at the time, but I ended up getting side tracked for a bit because of this - more on that later....

Better Questions


At the end of these interviews, I had a good deal of information and felt many of my hypotheses were validated enough to continue with the next steps. The problem, however, is that all I really had was bullet point answers to my bullet point questions. Going back I would focus more on trying to find causality for why people are in the situational segment I had defined before wanting to organize and share information in order to entertain, educate and influence others).  I should have focused more on exploring the customer's timeline.

To help explore and build a timeline, I would have started with a question (after some warm up) with:

When was the last time you needed to organize and present some information to educate or influence someone else?

I would then work during the interview to understand the causality of why they wanted to educate and influence. Usually with a follow up questions:

What did you use when you [ last wanted to educate or influence someone]? 
Why did you use that solution? 
Have you tried other things?

When you understand causality, you then can start modeling behavior and these models then can inform feature decisions. An example of this would be a prospective customer saying (which did happen during one of my interviews):

'My boss wants constant status reports and I waste so much time creating and sending them - and I'm not sure how much she reads them.... I use email and putting together those spreadsheets, graphs, pictures and all the text into an email is a pain.... I sometimes even have to send the email twice or go search back over previous emails to gather information on a specific customer.'

In this case, I'm looking for causality for both why the interviewee chose to use email ( it's the only format the boss knows about and it's something the boss can read on her mobile phone ) and why they have or have not sought a better solution ( they feel pressed for time to search for and then onboard the team for a new solution ).

So now I'm getting a better idea of not only causality, but also some for the forces which would push the customer away from trying a new solution or what may lead them to non-consumption.

Modeling A Timeline & Shared Problems


Now I was ready to develop some models. The type of model and timeline I chose to develop was to start with a job and then create a timeline of someone fulfilling that job and what their expectations were. This is different that the customers timeline toward product consumption / non-consumption. In this case I'm basically creating a generalization of what people do now - it's similar to a user story but more story telling.

An example of one model (of several) I created for one particular customer

The above is pretty much the timeline I created after talking with the customer mentioned in the last section. Again, I don't want to spend too much time in creating models because Lean, Not Models, Is Your Hedge For Product Initiatives and I don't focus on creating deliverables because Documents Don't Solve Problems.

Instead, I want to feel out the areas most unknown to me - basically decide what-I-know-I-don't-know. I then want to look at these various models and see what overlaps and what doesn't - defining shared and unshared problems within my situational segment.


With some models built, my next step was to think of some UI solutions and then spike it. I'll talk about that in part 4.