Development Partnership Programs for B2B SaaS Startups Pt. I — Sales

As an early-stage B2B SaaS startup, there is arguably nothing more affirming than landing your first customer. After weeks or months of stalking, talking, demoing and finally closing, someone out there has somehow decided to allot a piece of their finite budget to buying your less-than-ideal solution for their very real problem. Congrats! Now what?

Well, now it’s time to figure out how to make it happen again, and again, and again… That is, while ensuring the product you are continuing to improve is being developed in a way that makes it relevant to the critical workflows of a large enough portion of the market that you can continue to scale the company. But wait, there’s more! It’s not enough to build a great product. You need to make sure people know you’re solving their problems and the problems of their competitors too. And you need to figure out how to do all of this yesterday! So how do you do it? Who on your team is involved in making all of this happen? How do you work together to be successful?

My goal for this series of articles is to provide you with a tool to help align your team internally and your product with your target market. The “tool” is called a Development Partnership Program (or DPP). My recommendations come from my own experiences building DPPs at early stage (<2 years / Pre-A) B2B SaaS startups and catching glimpses of how it’s done at enterprise organizations. Some Pragmatic Marketing and Steve Blank is also in here, so if a lot of this sounds familiar, that’s because it is! These articles are for Founders and Business Development, Marketing and Product leaders at early stage startups.

Each of the three articles will focus on a key business function that is critical to the success of your DPP starting with Sales and followed by Product Management and Marketing. A fourth, and equally critical role in the success of a DPP is Engineering. I do not have experience as an engineer so I won’t be writing about that, however I will write about the importance of Engineering buy-in in Part II, where Product Management is the focus.

What are DPPs for?

In each of the startups that I’ve used DPPs, we served large organizations — Pro sports and university athletic departments for a company I started called APE Systems, and more recently at Modelo where we served 100+ employee architecture and engineering firms with a large US regional or international footprint. Because both of these startups were at very early stages, we hadn’t fine-tuned our pricing yet and the product roadmap was still in flux. We weren’t embedded into anyone’s workflows yet and needed to dial in our development focus. In short, we needed to prove to the market that we were legitimate. Getting big names on board early to use as reference customers was critical for these industries which are known for their follow-the-leader approaches to new technologies.

We could theorize internally all we wanted to about what our prospective users wanted and would pay for, but couldn’t prove it without actually engaging with them. This line of thinking probably sounds familiar as it echoes much of what, Eric Reis, Steve Blank and Pragmatic Marketing have to say. Nothing Interesting Happens In The Office, right? The issue was figuring out how to do it. How do you get your prospects to commit beyond having a friendly meeting or two? How do you get people to actually use your software when it’s still a bit of an ugly duckling not solving their problem completely? At their start the DPPs I’ve worked on creating have been sales tools first. It serves as an acknowledgement from the startup that it is in fact an imperfect startup solution and needs real sponsorship from a client to solve the client’s problem fully. For the client it is something tangible to latch onto and engage with, knowing full well it is working with a startup. Having the necessary documents and structure in place that established companies require to do business is critical and coming ready with the right tools shows you mean business. Ultimately a DPP is both an agreement made between the two parties around the purchase of the product and the subsequent usage, feedback and prioritization of the roadmap as well as method to align your product with market needs.

Once the sale is complete, the Development Partnership Program evolves out of its sales tool phase. It becomes a formalized structure to engage with your clients through to help Product Management build a more complete solution. Assuming that goes well, it morphs again as a tool for Marketing to use to highlight customer success, validate partnerships, and establish overall market legitimacy.

First, Sales

When you make your first sale to another business as an early-stage Saas startup there’s a good chance you don’t have payment processing set up. You may not even be sure what your pricing is going to look like in a couple months. In fact, the terms you come to in your first sale often dictate the future of what your pricing looks like. To get to it you are literally cold emailing people who you assume to be check signers or end-users at your target companies, hopefully getting them on the phone, possibly demoing, manually provisioning them and x-colleagues and personally following up with emails asking how you can help throughout their trial. Most of the time, they will will probably sign up, log in once, invite a couple other users and then ignore you. That’s just the reality of being an imperfect, early-stage product that doesn’t completely solve their problems yet.

But every once in awhile, you come across someone (or better yet they come across you) who is different. Geoffrey Moore would call them “Innovators” (Check out “Crossing the Chasm”). You can tell who these folks are by their level of knowledge of the space you’re in and the questions they ask. “Why did you decide to set your price this way? How does this relate to your competition? They price like this and have these features. I notice you don’t support x yet. We do a lot of x here. What’s your plan for x?” I can distinctly remember the first meetings and phone calls I had with the people who became Development Partners. They always had questions like these and there was almost always something specific that they in fact already liked that we were doing.

Now at this point, you might just have an early stage customer on your hands, which is great in itself. Whether or not they’re a good fit for the DPP is another question. How big is the client organization within the market? How big of a contract do you think you can get them to sign? For how long? How much cachet do they have in the market? Are they considered a leader in “innovation” among their peers or just another company? Is your point of contact at the firm senior enough to make the purchasing decision and to enforce adoption? Finally, does your contact have ideas of their own about where they would like to see your company and product go? All of these things are worth considering and may take a couple of conversations to figure out.

Let’s assume for now that everything checks out. Well, even if this organization is great, and this senior leader is an “Innovator” who will champion your product, it’s possible (and even likely depending on the industry you serve) that they’ll need something more than just an invoice and an email outlining the DPP to get rolling. I would recommend investing in two things. First, get an actual Software License Agreement (SLA) crafted by your lawyers with a clause describing the DPP. Second, create a high quality 2–3 page PDF beautified by your designer that outlines the many benefits of the Development Partnership Program. At this point let’s pause on the process and dive into what the DPP actually is and what its benefits are.

I mentioned above that the DPP is part of an agreement. This agreement may be an SLA. Or maybe you don’t feel you need that and it’s just part of a Memorandum of Understanding (MOU). Either way the essence of the agreement is, “Hey we’ll sell you this great product and you’ll actually use it and give us feedback on it so we can improve it for you.” The details of the DPP clause are up to you, but may include things like the frequency you meet with the client to exchange feedback, the actual fact that they agree to give their best effort to integrate the product into their daily workflows, or perhaps the fact that they will keep your roadmap private from your competitors (if that’s considered important). You need to figure out the salient points based on how your product works, the market you serve and go from there.

The second artifact I mentioned, the Marketing PDF should explain what your company does and why you’re special in a couple paragraphs followed by a paragraph detailing your commitment to serving the market by integrating feedback from a select group of innovative industry leaders. If you have a datasheet about what your product specifically does include it along with a bunch of other benefits that the DPP offers to your partner (paraphrasing):

• Year-long partnership during which partner gets a “significant” discount on the normal purchase price — Do not write the discounted price in this marketing doc!
• Direct communication with Product team and prioritization (keep it loose) of your feedback and feature requests within our roadmap
• Inclusion in various written and video case studies where we focus on your brand and what makes your organization so successful at what it does, with a plug about how our product fits into your process
• Prominent placement of your company’s logo on our website and marketing collateral in which we position you as a technology-forward innovator in your space
• Highlighting of senior leaders at your firm via interviews in our blog about their career progression, and what makes your company great
• If you already have recognizable names or even other development partners associated with your startup this is a great place to ask for a quotable endorsement — that is to say this doc can and should change as you grow

Depending on your industry, some of these may or may not be applicable. In all likelihood the first two bullets will be of the most interest. The case studies and marketing stuff may not be of any interest really, but it opens the door for you to use their logos on your site. Marketing will thank you for this later. Beware getting locked into multi-year deals at high-discounted prices. Beware even more client conditions/requirements around roadmap, if this is agreed to it should be checked off by the rest of the team (Product especially) first and should come with a much lower discount or none at all.

Signed, Sealed Del…

Your documents are in order and ready to be sent to the engaged prospect for review. If you don’t have the SLA yet, then at least have the Marketing PDF describing the DPP ready to go. Send it over and set up a time to discuss any questions. If they’re interested it will happen. If they’re not, it won’t and after several attempts to reignite the flame, you’ll move on. Assuming the call does happen and the SLA is shared, you’ll go through the negotiation of price vs however you structure your product: data, seats, time, and other terms. You’ll come to agreement and it will be time to figure out how to proceed with the actual Partnership!

At this point you have succeeded in closing the sale. Now it’s time to ensure that you set up the rest of the DPP, your teammates and the client for success. This will include coordinating with your Product Manager (assuming there is one) on how you want to collectively proceed. You probably still own the relationship and will need to be the one coordinating product feedback sessions and checking in on the client in between but it’s worth discussing this to ensure there’s no confusion. Who on the client side is going to be involved? Will there be only one point of contact? If it’s realistic I recommend visiting your new Partner in person to kick off the relationship with a demo of the product for the people who will be involved in using it. If the PM can make it to the kickoff, this would be a great opportunity for them as well. It shows you have your act together and care about the success of the Program. It also puts real human faces with this new (incomplete) product that will assuredly give some of your wonderful new Partners headaches.

At this point from a Sales / Biz Dev role your job is to make sure the DPP stays on track by making sure Product gets the feedback it’s expecting and that the Partner is seeing enough of the feature requests and bug fixes that they log. It should not take up much of your time but if your team is large enough that you have Client Success or Account Managers then perhaps this is a good opportunity for them to step up to support the Program. Ultimately it’s up to you who is responsible for this but make sure that you are staying in tune with the Product Team’s shared Feedback Sheet (which I’ll cover in Pt. II) to see where things are at and get involved as needed.

This concludes Pt. I of Development Partnership Programs for early stage B2B SaaS Startups. The next article will focus on the second phase of the Program: Product. This will cover a simple way to collect feedback from your Partners, getting buy-in across the team — especially Engineering, and balancing feedback with the leadership team’s internal vision for your product. Pt. II should fill in some of the gaps of this article and with Pt III my hope is that the value of using DPPs to develop your product and early customers as well as how to do so across these different internal team functions will be clear.

A few shoutouts for Sales tools I’ve used that have been particularly helpful:

• Import.io — a fantastic tool for scraping industry association websites of all of the companies within your target market and getting their: Name, URL, Phone #, Physical Address, Leadership Names. It took me quite a bit of finagling to get the data importing correctly but once I did, I had a list of hundreds of target organizations and most of their contact info.
• Pipedrive — I have mixed feelings about Pipedrive. It does give you some structure around where your deals are at, but I don’t think I ended up using it in a disciplined enough way to get the amount of value I should have — particularly in terms of analytics.
• Growbots — I love this company. Take all the work I did with Import.io and automate it by somehow scraping Linkedin data and pair that up with your own custom emails. What you end up with is a list of people that Growbots will send your custom emails to based on a set of specific filters you set like: Job Title, Industry, Company Size, Location, Technologies used (this is more for developer sales, where it will actually scrape the companies site and see what kind of web frameworks they’re using) and a bunch more I can’t remember.
• Yesware — They’ve been around awhile and the functionality that I’ve always used them for — email tracking is included in larger bundled products like stuff from Hubspot. They still do a good job though.
• Mixpanel — I used this less as a sales tool and more as a Product tool, BUT I will say this: If you have a seat-based tool and you want to see if your trial-user is actually engaged it’s as easy as typing their email url into “People” and seeing who shows up. Quick, easy way to see if the people who are supposed to be using your product actually are.