1 Comment

Story-Driven Product Management - Part II

Today I had a conversation with the CEO of an early stage startup. She peppered me with a lot of very specific questions about how to improve a product that I had literally never seen, as part of a company of whose business operations I had only the most cursory knowledge. It was a 45 minute call packed to the gills with those sorts of questions. But they were thought-provoking and I continued to chew on them after getting off the phone. At least one of those is pretty central to how I think about product management and hit on things I've discussed here before, and so I thought I’d share some of my thinking.

This company has a product and service that serves two complementary markets simultaneously as the nexus between enterprises and a certain class of individuals. It's also in a discipline that's critical to both the enterprises and the individuals. But it will have difficulty being useful or presenting perceived value to significant numbers on either side without significant numbers on the other. It’s a two-sided variation of Metcalfe’s Law regarding network effects. The question put to me was this: What would you do to the product to help bootstrap adoption by both markets simultaneously?

As I mentioned, with near zero exposure to the product itself and at best limited knowledge of the business particulars, I asked quite a few questions about both the product and the business model. One thing I said was that I’d want to understand the users from both markets better. I also shared an idea from a previous startup that we used to accomplish something similar. Not really related specifically to the product at hand, but it was certainly an idea worth spitballing. However, in retrospect, it was understanding users that I think is ultimately more valuable, but I didn't get a chance to dive too deep. Here’s a deeper dive.

What’s the actual question you’re trying to answer?

Let’s take the question “How do we bootstrap both markets via the product?” and restate it as a problem “We haven’t yet managed to bootstrap both markets.” That’s a valid problem statement, but not an actionable one. It’s way too broad. Really it’s more a symptom than an actual problem. It’s the symptom of hundreds or thousands or millions of individuals failing to do something we want them to do—engage with the platform in a meaningful and visible way. The real problem is that prospective individual users, or users from within enterprises have yet to be presented with something that attracts them to the platform in volume, either in lieu of or in addition to whatever network may already be in place. At this level we can pivot back to a question again: “What do we provide for individual users (enterprise or otherwise) to attract him or her to the platform in lieu of or in addition to the existing network?” This is the beginning of an actionable question. There are at least two different kinds of potential users (one from each market), but probably a lot more as important sub classes are identified. The product will need to answer this question for at least the primary two, and will likely need to take into account nuances between different types within those two primary groups.

I hope it’s obvious that to truly answer even this “actionable” question, it’s important to understand all of these prospective users as people. What’s their milieu with regard to the context in which they’d use the product? What are they trying to get done? What motivates them? What are their particular pain points? In short, the bootstrapping question can only be answered effectively with a detailed understanding of what makes these users tick. It's this story-driven approach that I've always followed and it's related to the idea of story-driven data analysis that I first read about a few years ago. The only way to make sense of large groups of people, and in turn address macro issues that arise from these large groups, is to understand what their stories are as individuals. Hence my bullet-point pseudo answer “I’d want to understand the users from both markets better."

I don’t know whether, in the context of the particular conversation I was having, I’d even have wanted to ramble on in such a philosophical fashion. But the fact is that often, the important thing about an answer is not the answer itself, but what went into it. In this case, what went into it is central to how I’ve approached problems like this in the past. Break it down into something manageable, and address it from that standpoint. Then employ useful constructs, in this case user stories, to solve the problem.

Epilogue

The solution I offered from a previous startup with similar issues was that we built a free community with value to both markets that would at the very least, drive traffic and increase the reputation of this site whose revenue, ultimately, consisted of business paying for listings that would be viewed by consumers. In addition to building social elements into the platform, it also involved the company paying experts to provide expert content for the site. This content enhanced the reputation of the site as the go-to resource for consumers looking for the kind of expertise that the businesses provide. It was our way to kickstart a virtuous circle. It was in a very different industry than the one at issue here, but it was one approach to providing value that didn’t rely as heavily on a network effect for which payment was necessary for inclusion by one of the two markets. 
 

1 Comment

Test Driven Development: My New Best Friend

Years ago, I was first introduced to the practice known as “test-driven development.” I’m far from an expert, but for those who aren’t familiar, test driven development involves writing basic automated tests of core functionality, watching them fail (because you haven’t actually built the functionality yet), and then writing the simplest code possible that will get the test to pass. For a fuller explanation, you could do worse than this Wikipedia entry. At the time I first heard of it, the idea seemed bizarre. In addition to simply not understanding, technically, how such a methodology could be implemented, I found it hard to imagine why it would be useful to do development in this way. Now, however, having thrown myself into the role of developer for the software I’m building, my perspective has certainly changed.

Communication Theory

One of the things I’ve been working on for the last month or so is the design of an effective communication system. Specifically, one that enables people on both sides of a communication stream to effectively separate signal from noise. Marketers and advertisers know this as “cutting through the clutter” — getting the folks who are on the receiving end of what you’re putting out there to perceive your message as signal (worth paying attention to) rather than noise (to be ignored).

Chipping Away at “Open”

Some time ago I wrote a post speculating on what the launch of Facebook Home might mean for the future of an open Android platform. I think it’s safe to say that Facebook Home, while not exactly a “dud,” has also not taken the world by storm. But it’s still out there chipping away at Google’s Android hegemony, and the threat that it represents to Google’s competitive position remains very real.

Story-driven Product Management – An Introduction

Recently, Judy Bayer and Marie Taillard wrote a short piece for the Harvard Business Review Blog called Story-driven Data Analysis. To oversimplify a bit, in the strategic landscape now, thanks to the ascendancy of “big data,” there’s far more data available to strategists, analysts, and marketers than they can realistically make sense out of. Stories, they say, provide a means of constructing hypotheses as a lens through which to view that data, and subsequently, guidance on how to appropriately analyze it.

Luddites vs. Geeks

Computers can both be too complex and people can be too lazy to apply themselves in computing. You can both criticise people for taking pride in ignorance and criticise computers for being needlessly complex. Despite what many commenters seem to think, pointing out the latter does not invalidate the former. And, conversely, pointing out the former doesn’t invalidate the latter.

Great piece that captures some of the subtlety and tension that most product architects deal with regularly (if they’re any good).

Marissa Mayer: Product Person

I admit that I wasn’t right on top of the details of Marissa Mayer being made CEO of Yahoo last year. At least no more so than the average person. I really didn’t know much about her or her history at Google. I’ll say this: I did think it was a peculiar combination of hypocrisy and tone-deafness for her to, seemingly in a single stroke, tell the entire company that working from home was not an option, and then to build an extension of her office for her nanny and new child so she could be with them regularly. As one half of a working couple with two small children, that made me viscerally angry. And don’t get me started on “The baby’s been way easier than everyone made it out to be.”

99% Awesome

For the past year or so, many of the (nerdy) podcasts I usually listen to and enjoy have made reference to another podcast: 99% Invisible. I think because of the “99%” in the title and its association (in my mind) with the Occupy Movement, I assumed this was a political podcast or an economic podcast.