It all started with a tweet.
@romy u in? :)
— tristan walker (@tristanwalker) May 14, 2014
And just like that—after stints at AOL, ThisLife, and Shutterfly—Romy Macasieb became the first product manager at Walker and Company.
“I wasn’t actively looking for a job,” Romy says, “but as Tristan and I talked more, I began to see what an awesome experience it would be to work at Walker and Company, so here I am.”
Since its debut in 2013, Walker and Company has drawn attention for its unique mission: to make health and beauty simple for people of color. Their flagship product, the Bevel Shave System, is designed for those who usually suffer skin irritation or razor bumps from shaving. Bevel is available as a subscription: folks pay monthly and receive new product quarterly.
Until very recently, Walker and Company was short a growth lead or a data scientist to handle analytical tasks. As product manager, Romy helped pick up some duties—chief among them: helping Walker and Company transition from metrics available in out-of-the-box tools to metrics specifically tailored to their business.
In this interview, Romy talks about the analytics tools Walker and Company uses, their process for defining metrics, and how they stayed data-informed in the days before a dedicated growth lead.
Analytics stack
What analytics tools do you use?
At a session level, I use Google Analytics for measuring uniques and page views, etc. One level deeper, we use Mixpanel and Heap Analytics for conversion and funnel metrics—like if someone visits getbevel.com, goes through the different pages, and then checks out. I spend a lot of time in those two services, looking at a bunch of different funnels I've bookmarked.
With Heap, we drill down on customer engagement and attribution. We can look at initial and last touch attribution which is helpful in understanding who converts, and why. We’re actively working on multi-touch to get deeper understandings.
For the most detailed analysis, we use Mode to slice and dice things like churn, conversion, and revenue. By channel, who are our highest LTV customers, what do margins look like, and cost of goods? We have a few reports that we continuously look at: revenue, orders by channel, LTV, etc. It's where metrics uniquely tailored to our business live.
Were all these tools in place before you got to Walker and Company?
Google Analytics and Mixpanel were up and running before I arrived. Those are pretty standard.
We were also relying on the consulting team over at RJMetrics. We'd tell them “We want to analyze this set of data” and their team would run reports for us.
RJMetrics worked well in the beginning, but as we grew, we needed to make sure no metrics were housed in a black box. We needed to take more control over how we defined metrics and how they were quality assured. Bevel is a bit different than a typical subscription business. It's not the constant rhythm of paying the same price every month and getting a product every month. You pay monthly, we ship quarterly. Month one you send in a payment that includes shipping and handling, and you get a box. Month two and three, you're just paying for the product. Then the cycle repeats. A customer can pause payment if they feel like they have too much product.
We started using Mode as we worked to define our own metrics. To trust the data, we knew we'd have to do all the work on our own. We knew when the data was right, and when it was wrong, we knew what to do to make it right.
Defining metrics
How do you share data at Walker and Company and how do you let the rest of the company know what decisions you've made?
Walker and Company is very transparent. We have this rule: if you have more than two people in a meeting, you have to send notes from the meeting out to the entire company with action items. Every Monday morning, every employee sends out snippets sharing what they did last week and what they're doing this week. And at the end of each week, the product team sends out a weekly status. Each of these touch points is an opportunity to share data.
When I create reports, I don't just share them out. I talk first. And to be clear, for most of our Mode reports, we have an engineer go deep, in which case, they talk first. It's very easy to share a link to a chart and just hope that the person on the receiving end understands what that chart is saying. It's not just telling the story, but how we tell it, that matters.
So how do you tell that story? What do you talk about?
I get together with my peers in the same room, and we'll review the data and try to land on definition of a particular metric and what we want to get from it.
For instance, customers can pause their subscriptions. But, if a customer pauses, they still have to pay for the product they’ve received. The finance team would want to know how this impacts revenue. The product team obviously cares about revenue too, but we’d want to actually understand why and when customers pause—if we notice they’re pausing really early or really late in a cycle, this could drive us to build different user experiences. Subtle tweak in the report, but it’d tell two different stories.
We don’t always know that a report could be built in a different way, to help other teams. So, we meet, understand business needs, and then work with engineering to figure out how we actually get the data to calculate the metrics we've discussed. An initiative is not complete until we all circle back together to discuss the report as a team.
Who's in the room when you're figuring out how to define a metric?
The heads of operations and supply chain work closely on product development, so they'll get roped into discussions about things like cost of goods. Our CEO Tristan Walker is in all these discussions because he's always looking at the business at a high level and needs to stay informed. Sometimes, we have brand and marketing in the room if the metric relates to the performance of say, some marketing campaign they have put together.
I like to have an engineer in these discussions as well, so they can say, “Yes, we have that data” or “No, we do not have that data, and this is how we go about getting that data.”
We probably have more people helping to define metrics than most companies.
Why is that? Why is it important to have so many stakeholders participate in that conversation?
There are just so many different variables. You can't just assume that say, the marketing manager or the product manager or the CEO is concerned about all of them. You want to make sure the entire team is involved in the discussion because when you bring these different perspectives together, it forces you to consider factors that affect teams besides your own.
Once you leave that room, everyone should be on the same page about the definitions for each of these metrics.
Growth engineers
I know you don't have a dedicated data scientist yet at Walker and Company. How do you handle that? Who's responsible for analytical tasks?
We actually just hired a growth lead who'll help a lot here. But before, in the absence of a data scientist and growth lead, we knew there was just so much stuff we had to do for growth. Whether that's building things to grow the company or building things that would tell us about the data. So we created a growth engineer rotational program within the team.
Every month, sometimes every two months, one engineer would switch their sole focus to growth related items—whether that was pulling data or building functionality. If there's a pixel that needed to be implemented, we could go to that engineer. If we need to work on lifetime customer value (LTV), we'd go to that engineer. That helped keep growth at the forefront, but it also helped their fellow engineers since they didn’t have to continuously switch context.
How does the growth engineer's role tie in with the process of defining metrics?
Because they actually have access to the database and they need proper requirements to build out reports, they’re key in landing on a definition or use-case; not so much defining, but helping us define. It’s easy to hand wave “Give me a report on this” and hope the product and engineering team knows what to do. The growth engineer will likely be the first person to ask, “For who?” or “For what?” Basic questions that help us get to the root of what is really needed.
A product manager and engineer are only as good what we know, what we're trying to solve. Instead of asking an engineer to create a definition and assume that it's right, we ask stakeholders to come in and voice their concerns and considerations.
Want to work for Walker and Company?
Walker and Company is hiring a data scientist to help optimize the product experience, focusing on customer acquisition and their customer messaging platform to improve customer engagement and retention. This position will be integral to Walker and Company’s success as they expand to new markets and build new products and brands.
Learn more about this position and others on their jobs page.
