3 Things I’m Learning From Customer Research Interviews

ProcessKit is my latest attempt at solving what’s basically the same core problem I’ve been working on (read: obsessed with) for years:

How to build the operating system for my business—in a way that supports all the complexity of my business, but is also simple and easy (and enjoyable) for everyone on my team to use.

I have plenty of experience running teams, productized services businesses, and I’ve worked at digital agencies for years. So I come to this with a bunch of personal opinions, wants, nagging pains, and ideas for how I want this solution to work.

But like any good product person, I can’t rely solely on what I want. I have to get out of the “building” and talk to people.

And that’s exactly where this journey to begin building ProcessKits (in public) begins: My customer research and what I’ve learned.

So far, here’s what I’ve done to kick off this off:

My customer research process:

1. I announced the domain processkit.com to my email list and Twitter follows. On that page, I wrote a “manifesto” of sorts. The goal being to present the problem and describe in broad (vague) terms, what I think a solution might be, and see who resonates with what I wrote.
2. I asked people to enter their email to join the waiting list. This led to a questionnaire, which asked a bunch of questions around process, team, tools, what’s working, what’s not working, etc.
3. To gain a high level view of the group of people who gave feedback, I compiled the responses into a spreadsheet and I was able to extract a few key metrics from my audience: Avg. team size, most common business type, most common tools mentioned, etc. But this alone only scratches the surface.
4. To get the real helpful nuggets, I’m reading every word of every response (there are hundreds!). I’ve only made my way through a small portion so far, but I’m already seeing a few highly common threads, which I’m detailing below.
5. As I read, I’m using Gmail labels to save the most engaged/helpful responses. I reply to many of these and invite them to book a call on my calendar. Some I reply with followup questions over email.
6. I hold the calls for about 25 minutes each. Most are happening back-to-back throughout this week (and more scheduled next week). It’s tiring, but also helpful to hear common feedback come up again and again.
7. I’m recording all of these calls, and jotting down notes while I’m on the calls. I’m going back and re-listening to the more helpful calls so that I can really soak in the feedback and catch some details I may have missed while I was on the call live.
8. I’m writing about my findings in my notebook and here on this blog. This helps me process and really think through the implications of what I’m hearing.

So what have I learned so far?

These things have stuck out to me as common threads I’m hearing (and seeing) again and again in all of my conversations:

1. Processes aren’t readily available where the work happens.
   Almost every call mentioned this in one form or another. The processes are documented and maintained in one place. The work (tasks, projects, team communication) happens in another place. There’s constant hopping back-and-forth, and frustration around “not finding the doc I need when I need it.”
2. Managing resources is difficult/impossible without seeing each team member’s current plate of work.
   How much work does Juliet have on her plate? What does Trey have due next week? These questions are difficult to answer for most teams, and it makes it difficult for management to plan and allocate resources without overloading (or under-utilizing) people.
3. Creating well-documented processes is one thing. Actually using them is another.
   This goes for both the process creator (often the founder or lead) as well as the team themselves. Processes kinda fly out the window once a real-world project has scope creep or has a special requirement or doesn’t go according to plan. Things get messy and when this happens, everyone on the team loses trust in their tools and processes, and this leads to more messiness.

There are other, more specific pain points and frustrations I’m cataloging too, but those 3 rise to the top as the most common and most pressing.

Asking for the solution… Is the wrong question.

At this point, you might expect me to lay out my proposed solution to those problems. If you’re on a call with me, you might expect me to try to sell you the solution.

But that’s not the point. And it’s not appropriate for this stage.

The point of asking these questions is to listen and truly internalize how these problems feel in practice and their implications.

It’s comforting to now that what I’m hearing from others confirms my own experience and frustrations. I have some (working) concepts how I might design solutions to these problems.

But for now, I’m just processing the problems and working to understand the underlying, root business problems behind them.

What do you think about this? (more feedback please ;)