Product distribution lessons I learned the hard way

One of the most challenging yet rewarding areas of learning for me—both from a product and business perspective—has been partnerships and channel distribution. It was a significant focus in my previous role, and at Trestle, we emphasize it heavily due to its potential for non-linear growth.

At Trestle, as a data solutions B2B business, we think about distribution as:

We frequently talk about product-market fit, but for distribution, I like to think about product-market-channel fit. For me, it means: 

To ensure the right fit, simplify the product as much as possible. Of course, we always talk about simplicity, but for indirect distribution, think about the partner team who might pitch or sell our product without our assistance. What does that mean, and what are the product implications? I have learned the hard way about this one in my previous roles. I still remember this one time when the sales team wanted us to integrate within a platform, but for me, it wasn't a top priority. I was trying hard to take our product as-is and integrate it within the platform, not thinking about how complex the end-user workflow becomes due to it.

I still remember this, as once our CEO discovered it and distilled down the reasons for the partnership failure, it was clear it started with the sub-optimal product integration. This was the closest I had ever been to getting fired but a valuable lifelong lesson was learned. He always said, on a good day, the partner (their customer support, sales, or anyone there) remembers 10% of our product's capabilities. So, we must simplify things as much as possible, even at the expense of creating a partner-specific offering with a value proposition that aligns with their business. We applied a lot of these learnings from the onset at Trestle, and luckily, we have not had that issue as much given the simplified product focus from the get-go.

Another item I think about a lot is the return on investment (ROI) from the end business customer perspective. For us, it means how many fraudulent or fake leads we were able to catch, how much savings that means for the customer, and does that justify the spend made on the Trestle's ‘add-on’? The ability to demonstrate ROI in simple terms through proof of concepts or live tests working in tandem with the platform team and the customer is critical and painstaking at the onset. Make no mistake, though, once figured out, this can mean a lot of non-linear growth as the partner teams are now selling your products. Product managers focusing on that ROI for the end customer from the product and the business standpoint see the most success.

Closely related to simplicity is repeatability. A product-channel-customer fit happens when there is repeatability of the business problem, the solution pitch, and the selling motion. Yes, the pitch should be simple enough; lighting up the customer experience to derive value from it should be even simpler. We  have focused over the years on the standard rulesets (score higher than X accept lead or lower than Y reject lead) and signals (two to three data attributes maximum) to give the partner sales or customer support agents so that they are 'pre-baked integrations.' Then, the partner can immediately switch us on for the customer without lengthy data tests, customizations, etc. As a product person, early on, I used to think about how to deliver and ensure the maximum value is derived by the customer using as many data attributes as possible, etc., but the 80-20 rule applies a lot for the partner channels to make them succeed and scale. 

For all these categories I discuss above, the engineering work falls on Trestle to build the add-on or on the platform team, depending on the platform's capabilities. Both have their pros and cons. If the work is on the platform team, I have learned over the years to obsessively focus on the requirements, making them as detailed as possible. This is where knowledge of the platform, how customers use their product, and how our product will be used is critical. Too often, I have seen product managers, including me, falling into the trap of a superficial understanding of the platform without deeply understanding their user workflows and where exactly we fit in and how. The result is a half-baked spec thrown across the other side, which generates poor results. In my previous role, we used to say that we needed to shadow the platform's end user for a week to understand the persona, how they use it, and where we would fit in. This is a discipline I have tried to improve on over the years, and I still get into the 'speed' trap to release something quickly at times. If not shadowing, gaining access to the platform to try things out yourself helps. Still, having a thought partner on the other side or even a business customer who is your champion and wants the integration to be successful for their own business are significant assets to tap into to get this right.

Interestingly, you will commonly hear from your engineering teams: "We do not want to build the apps. We want to focus on the 'product' building." I have adopted different strategies at different times to get things done. One thing that has sometimes worked for me is using ISVs (Independent Software Vendors) specializing in that platform. They help us ramp up to the platform and can be a good conduit to bridging the platform knowledge and our product fit gap to help us build a superior experience. It also saves time for our engineering teams, who do not have to ramp up to the platform APIs.

I hope this helps. Please share other product learnings that you have had in this space.