developing: user research

I’ve been burning the midnight oil the past few weeks on a project that’s tangentially related to swishbook. That’s been eating up all my free coding time, but I’ve also been spending some time doing the least exciting thing in the world: talking to users.

I read ~something~ ~somewhere~ recommending that about ~50% of your time when building a product should be spent on marketing/outreach rather than doing hands-on-keys work. In all fairness, I definitely have not reached that (admittedly lofty) time-split, but in the time I’ve managed to carve out for talking to folks, I’ve learned quite a bit!

• I’ve confirmed my suspicions that swishbook is a pretty niche product that would serve a relatively small user base (1 user covers all of swishbook’s costs, 10 users would constitute a big success, 250 users and I could quit my job, 10,000 users would be a life-altering, buck-wild, bonanza).

• The core problem swishbook addresses isn’t being addressed by any other business. I need to spend some more time here — is this unaddressed problem an undiscovered gap in the market? Is the problem simply not a large enough pain point for the market to develop a solution? If the latter, is it still enough of a problem for enough users that it’s worthwhile to solve?

• There are opportunities for useful features that I hadn’t considered and wouldn’t have discovered had I not spoken to folks!

As a data scientist, I feel most productive when I’m cranking through some hands-on-keys work. But I know that speaking to folks to generate user stories is just as if not more important since it helps direct the product towards what people actually want.