Know Your User
It was great to be back at Dogpatch Labs today for a bit of catching up and two very interesting talks. Deborah Lynch and Stephen Culligan, both Product Managers with Pivotal, shared their insights into user research and agile product roadmaps. (Among many other things, Pivotal created the awesome Pivotal Tracker, a SaaS tool for managing agile backlogs.) What follows is my brief and very subjective summary of Deborah’s talk.
Deborah spoke about the need to “know your user” and how you can accomplish that. Start with identifying the key target group for your product, and then find a small number of real people from that group as research participants (avoiding friends and family if possible). She then laid out a process to discover the needs of those users, and what their current challenges are, by balancing a framework of carefully chosen questions with an interview approach that keeps things conversational, finished with a recap of what you’ve heard.
She explained how you can build on this initial feedback, first with intentionally basic wireframes and only then with more visually refined screen designs on the way to fully interactive prototypes. This avoids premature focus on the look and feel instead of on functionality. (That’s why I personally like Balsamiq Mockups for wireframing — the squiggly lines, sketchy style of the mockups leaves no doubt that you’re looking at a concept, not a finished design.
Armed with this research, look for common themes in your users’ responses: what will drive the necessary change in their behavior to adopt your solution to their problem? The answers should help to prioritize your feature development. With this approach, you’re off to a good start to achieve what Deborah set out as a guiding principle at the start of her talk: “A happy user is going to result in a successful product.”
A key insight of Deborah’s talk I’d like to share is this: You can and should do all or at least some of this before you write a single line of code. This is crucial and often overlooked by non-technical founders, at least in my personal experience. Many first time entrepreneurs start with an idea and want to launch straight into building the software, so they start looking for “a coder”. But building code is complex (read: expensive and time consuming), whereas a bit of basic research can accomplished with relatively little investment of time and money. The whole purpose of the research is to validate your idea before you sink real time and money into it. (Once your idea is validated, you’re probably *still* not ready for “a coder” — you’ll need at least a basic roadmap. That was the subject of Stephen’s talk, which I may cover in another post.)
Which leads me to the second takeaway from Deborah’s talk: Don’t ignore feedback you don’t want to hear. If 9 out of 10 of your identified target users see no value in your idea, listen to them; you may have a solution in search of a problem. In which case, the initial research will turn out to be the best investment you’ve made. That’s my two cents.