When You are Not Your Customer

Ok real talk for a second. Despite the current trend for “building products for yourself,” as more specialized SaaS software enters the marketplace, it becomes more likely that one of these days you’re going to end up working on a product for which you are not the target customer. For me this was funeral home management software.

You read that right. Funeral homes. In 2014 I joined a team building software for funeral homes.. I was hired primarily because of my experience in consumer-facing products, as this product had a large components for the funeral home customers, but the SaaS product also fell under my purview. Suddenly “body care” and “incidental commingling of remains” became parts of my active work vocabulary. I knew very little about funeral planning, except that it seemed awfully stressful, expensive, and confusing. This new world of software customers (Do we call them “Funeral Directors” or “Undertakers?” What about “Morticians?”) were the users for my product, and I had to get inside their heads. So where did I start?

1) Reading. I read everything I could find on the topic. I read funeral home operational forms, funeral home websites, funeral director memoirs, the direct mail ads that show up in my mailbox from funeral insurance companies, and the FTC funeral home regulations. This process taught me a number of things about my customers and the consumers they serve. This includes learning that while a funeral home is legally obligated to bury you in your Costco casket, they can’t promise that it will be narrow enough to fit inside your family vault.

2) I enlisted allies. While asking your coworkers for input is valuable, it’s imperative to have people using the product with whom you can speak. For me, this was a couple of our early users who had been evangelists of our products within their organization.They were always eager to hear about new features in the works or check in with me on how the product was working for them. Those ongoing conversations taught me a lot about their day-to-day operations and gave me access to a lot of specific feedback. By speaking to my accomplices I learned that while a “Visitation” and a “Viewing” are theoretically the same thing, people in different geographic regions of the country have strong feelings about which one of those services they are willing to attend.

3) I took advantage of my “new kid” status. For the first couple of weeks or months you work at a new organization you will get a certain amount of leeway on asking potentially foolish questions. Plan on using it, but keep track on when this goodwill seems like it might be running out. Trying too hard to look like you are totally on top of things from day one can rob you of a great opportunity to learn your market and their problems if they aren’t familiar to you. This is how I learned the difference between a coffin and a casket. (Check out this great infographic on the topic.)

4) I tried on being my customer. I was fortunate to be able to spend two days interning in a funeral home. This funeral home was not a user of our product, and I found this situation to be a great help for me, as I was able to focus on the more general issues they were dealing with as opposed to getting bogged down with operational support of the product, or focusing excessively on how they were using my software. I know this often isn’t practical for other product managers, but this is a great place to potentially enlist the help of your allies. See if you can shadow them for a few days, or even a few hours. You’re not interested in what they do *with your software* but rather what the do *at their job*. I learned a huge amount during this period, including the fact that, in California, a funeral home might be using urinals for disposing bodily fluids that aren’t urine.

5) We did some internal testing anyway. While we weren’t able to use the product exactly as the funeral homes would, we were able to set up some internal role playing days. This wasn’t great for getting to the bottom of industry-specific problems, but it did sort out a number of the same problems you typically find in dogfooding, like poor data collection fields or missing options. This is also how I learned that my coworkers really liked playing dress-up; our “mourners” were all very well attired and had suitably ridiculous hats.

Why is all of this important?

• It’s important to see how your product factors into the day-to-day life of your customer. It’s incredibly unlikely that they are spending all day in front of your software, so their interactions with it have to be meaningful in the context of their overall workflow.
• Knowing your customer’s mindset is key. While most funeral directors work in small businesses, which is something we had in common, some of the customers we were onboarding had never used computers in their day-to-day operations before. Getting to know how they were doing business before was critical in managing our onboarding process and expectations.
• Knowing the overall picture helps you prioritize the problems. When you don’t know what the customer problem set looks like, every feature request or concern coming from an active customer can take on an mis-sized sense of priority. Having a good sense of what the day-to-day issues are keeps you in charge of the product future instead of flailing to solve problems, or, worse, ignoring an issue that is really important.

In the end, as a product manager, you need to have control over the product, and to do that you need to understand the customer for the product. It’s possible to get inside the head of a customer that isn’t like you to produce great results. You don’t have to be a primary user of a product in order to build a great product that users will love — you just need to be able to understand the needs of those users.

(It’s funeral directors by the way. We call them funeral directors.)