Development Partnership Programs for B2B SaaS Startups Pt. II
This is the second article in a three part series focused on explaining the merits of and process for creating Development Partnership Programs (DPP) for early stage (Pre-A) B2B SaaS startups. The first article examined the general concept of a DPP and the role that Business Development or Sales plays in finding and signing on appropriate partners. This article focuses on a second business function of the Program: Product Management. It will cover considerations for positioning the Program to the rest of your team in a way that should help with buy-in, a simple way to collect feedback from Partners/Users, and some thoughts on balancing Partner feedback with the team’s internal vision for the product.
The DPP is a tool for aligning your team to make sure you are building, marketing, and selling your product in a unified way. Even in small teams it’s easy for Sales, Product and Marketing to become somewhat siloed in their own areas of expertise. Unless you communicate diligently about how you support each other you will quickly lose sight of how your team needs to cooperate and find yourselves misaligned.
At the heart of this effort is Product Management. It is Product’s duty to ensure that user requirements are satisfied to empower Sales and Marketing to succeed. Reciprocally Sales and Marketing need to be feeding information back to Product to ensure those requirements are known and understood! Still, Product sits in the middle and is the main conduit to Engineering, where the actual work of satisfying these requirements must be grokked in their most functional terms and executed upon.
The most important concept for the team to buy in on is this: The DPP can serve as a unifying force to ensure your startup is aligned with a manageable group of engaged users, who have committed to providing direct feedback about what needs to be improved to make the product an integral part of their workflow. Hopefully this concept alone is meaningful to everyone involved. To make that more meaningful to your colleagues, here are some business unit-specific benefits.
Sales — Closing year-long deals with early, committed customers will help you determine the different contractual levers and showstoppers that are important to this market, which will help you close new deals faster in the future. Establishing real relationships with senior leaders at these organizations will also establish credibility in future deals. (To the founders, going for another round? These early execs are great people to offer as references for investors). (For more on the critical role Sales and BD plays in DPP see Pt. I)
Marketing — You need to be creative to be an early-stage b2b marketer. No one really cares about you until your company starts “doing things.” So it can be a challenge to get featured in industry publications at the very beginning. What you need are stories from real people using your product talking about how it’s affecting their lives. The DPP is a great tool to help you find those people and have an actual reason to build a relationship with them. You’re no longer just a pesky marketer — you are learning the things that actually matter to your users so you can be more deliberate in calling those things out going forward. We’ll get into this more in part III.
Engineering — It sometimes feels like engineering is both the closest and furthest away from users of a company’s product. They are literally building the product but very seldom, if ever (unless there’s a problem) speak directly with users or hear from customers without the message being filtered through two or three layers of other people. It’s important to ensure there is a more direct linkage between users and the creators of the product. It makes the engineering work more meaningful and real and it’s actual proof of what users want (#NoFilter)! The DPP offers this linkage at the very least through structured sharing of user feedback, which is described below.
Product — Getting meaningful user feedback can be tough. You need to actively make it part of your weekly process. Looking at Mixpanel, Google Analytics, In-app support requests via Zendesk or Drift is great. But having real conversations with users who you build a relationship with allows for a different type of understanding. Having a structured process in place for having these conversations and putting your users in the “how can this be better?” or “this is really bugging me…” mindset helps you build continual learning into your schedule (as well as that of the entire team) and will also help you integrate feedback into your development schedule with Engineering, which subsequently affect Marketing and Sales.
If these concepts can be shared across the team and everyone understands the value that a DPP initiative can provide to them, you’ll put yourself in a great position to succeed if each group is willing to make the required effort and commitment to seeing it through.
Along with market credibility and hopefully some revenue, user feedback is the most valuable element of a Development Partnership Program. Looking at numbers and flows in monitoring tools is great but they don’t always answer the “Why”. Why aren’t people using your new feature? Why are people stopping on the third step of a four step flow? Why haven’t they invited their colleagues to fill out the enterprise seats you set them up with yet? These are the kinds of questions that are important to have a real user answer with their words.
As mentioned in the previous section, you’re probably already collecting this type of information using a few different channels: in-app chat support, support tickets, maybe even people replying directly to your email newsletters. Those are all great (except the email newsletter replies — those are rarely friendly), but I’ve found it’s the mindset that you put your Dev Partners into by being part of “The Program”. It’s no longer an early user being annoyed by you asking for feedback or only sharing feedback when things are FUBAR. By entering into the DPP, they are coming in as partners. This is a joint effort to build something together that works for them. Once this switch is flipped, you will be amazed at the kinds of conversations you begin having that open up completely new and very meaningful directions for your product.
Providing a private, structured space for your Development Partner users to log their feedback alongside a bi-weekly to monthly check in call to review this document will provide you with significant insight for you and build a strong relationship. This feedback document can be very simple. In the past I have used a shared Google Spreadsheet (like this one) which I highly recommend. If you’ve worked in development consulting services or digital agencies, you’re probably very familiar with these. With a little bit of conditional formatting these documents can feel quite personalized and kinda cool. Everyone likes it when cells change colors right? Right? The primary benefit is that because it’s a spreadsheet, your users will likely understand how it works immediately. The same is not true for heavyweight ticket tracking tools like Jira, or Pivotal Tracker. You also don’t have to worry about exposing the internal commentary of your product team or permissions or anything else. Create the document. Invite your users to it and build instructions into the column headers with comments like I did in the example.
I would set some guidelines around who in your team responds to user comments and how they do so. Be sure to check the sheet for new feedback frequently. I’d also recommend keeping each organization’s user feedback in separate Google Sheet files. If you want to get fancy, use the IMPORTRANGE function to get all partner feedback sheets flowing into a master sheet to ensure you’re seeing where duplicate requests are coming up.
Managing Feedback and Roadmap
Alright! You’ve got Development Partners. They’re using your product. They’re finding things they like and more importantly, they’re finding blockers, critical workflow issues and nice-t0-haves. Best of all they’re actually sharing this feedback with you through your trusty Google sheet! So now how do you manage all of the feedback and keep everyone happy?
Don’t forget you’re no longer just serving the users at this point. Your entire team has bought into the DPP process and each of them have their own opinions based on the user feedback for what’s needed next! Sales wants to keep these early clients happy as well as close more deals. Marketing wants to highlight sexy new features to drive signups. Engineering has to deal with actually building it. Product has to wrangle it all into hopefully meaningful order.
The short answer is you don’t. You don’t keep everyone happy all the time because you simply can’t. If your DPP is working correctly you have more feedback than you know what to do with! This is great! Now it’s a matter of working as a team to prioritize while being as open as you can with your Development Partners about what’s coming, what’s not, and why. Let’s talk about this openness.
In the feedback sheet, there is a column titled “Status”, which includes descriptions for each feature request bug report, like: under development, completed, researching, need more info, can’t reproduce, not in roadmap. In addition to filling out these statuses I would include a concise note to provide a little context on why. Then in your bi-weekly/monthly check-in calls when you review the sheet you can discuss.
This is not to say that you’re never going to actually do what your development partners suggest or ask for. In fact, the very opposite is true. But it’s a balance. You can’t do everything, every time. This brings up an important point about the details of your DPP agreement. It should never give the impression that you are now development consultants or that the dev partner feedback is holy. “Development Partner product feedback is prioritized in our roadmap” leaves a lot of room for you to make the prioritization decisions that you need to. So don’t ever feel obligated to a Partner’s demands this week.
Managing the feedback is ultimately an exercise in give-and-take. Your Partners are guaranteed going to provide you with incredible UX insights. They’re going to come up with totally wild, moonshot ideas you hadn’t thought of. They’re going to come up with some ridiculously confounding ideas too. Then you have your internal product vision. It’s a challenge to balance all of these things, but over time by weaving these different threads together your product will be all the stronger (minus the confounding parts of course).
Let’s make sure people do care about your product.
Next up is Part III: Marketing. It’s time to GET THE PEOPLE GOING!
Thanks for reading.