How to build multiple products at a startup (without getting killed)

Ed. Note: this article was originally published on LinkedIn. Thought it would be relevant to our readers here, too. Would love to get your comments or feedback by email.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -

Foundersuite is an ambitious project — we are hacking entrepreneurship and turning it into software. My vision for Foundersuite is to build a comprehensive set of productivity tools that help entrepreneurs win.

However, when I started the company, I got a lot of advice from some really smart people that the “suite” part was a mistake. Common startup wisdom says to focus on one thing, obsess about it, and get it right.

While this is certainly sage advice, it leads to what I call the “FNAC problem”. That is, it fosters startups that are, in my opinion, a “feature, not a company.” It inhibits the growth of a big, bold, crazy vision.

Foundersuite’s thesis is that there are numerous startup processes that can be improved via online tools and APIs. Many of these processes are currently executed using spreadsheets or other offline methods. For example, our Investor CRM tool is designed to replace the messy and cluttered spreadsheet many startups use to track investor discussions.

I believe there are literally dozens of similar “purpose-specific” tools that entrepreneurs need, but each one is just a point solution. I don’t believe they are, on their own, standalone companies.

So we are sticking to our guns, and building a product portfolio. I believe that you can build multiple products at a startup in a focused way. Here’s how to do it, without getting crushed.

Start with an “anchor tenant” product.
Build something that solves a real pain point, and that people will pay for. In our case, it’s our Investor CRM product, which takes the hassle out of managing a fundraise. This is an area we know intimately, and it’s a need that is nearly universal to startups.

Build complementary products.
Step two is to create products that extend, complement, or enhance the core product. In our case, we came out with an Investor Relations tool, which naturally complements the CRM. We are also working on an Investor Search tool, which solves one of the biggest pain points of fundraising (i.e., finding the right targets). Such products both increase engagement and extend the customer lifecycle.

Build ancillary “experiments.”
The fun part of this job is brainstorming common startup tasks that could be improved with software. We often use ourselves as guinea pigs. For example, when we started reaching out to the media to get some press coverage, I tracked our efforts in a Word doc. Doing so inspired the creation of our Media CRM tool, which offers a simple way to track journalists and keep on top of story ideas and pitches. It also moved us from fundraising tools into the marketing space, which is a natural need for startups that have raise capital.

Tie it all together in an intuitive way.
With multiple products in the mix, the next challenge is to present it all in a clear way so that users don’t get lost or confused. There are numerous ways to do this: you can drive users to experience your products sequentially, or you can ask the user about their needs and display only the relevant product. In our case, we took the simplest approach and just grouped our tools by common startup activities (“Getting Started” “Raising Capital” etc.) so that users would self-select what they need. Going forward, we’ll layer on a dashboard that will make the UX more cohesive.

So are you warming to the concept of a suite yet? Are you saying, “sounds great in theory but how does a multi-pronged development process actually work?” It’s really not that complicated. From a tactical view, here’s the approach we take:

1. Start with a thesis — what does the world need, or what can be done better? In our case, we look for manual processes and we explore how they could be improved with workflow and/or or external data.
2. Gauge demand & test initial reaction with mockups and wireframes. Talk to users at every step of the way. Ask them a) if they would use it, and b) if they would pay for it. Be wary if the answer is always, “I’d use it only if it had X, Y and Z” (which is equivalent to “no I wouldn’t use it.”)
3. Build a very simple Alpha version. Emphasis on simple. The alpha version, or MVP, should have some basic level of functionality, be relatively stable and bug free, and solve the core function. But avoid the temptation to load it with features or slick design.
4. Release it into the wild & absorb feedback. Invite users into your office, and ask them to try out the new product in front of you in exchange for getting it free for a year. Collect feedback. Repeat. The hard part here is to know which requested features to build; the temptation is to build all the requests. To counter this tendency, we wait to build any new features until we find solid, discernable patterns — meaning multiple users are requesting the same thing.
5. Progressively — yet selectively — develop new versions. Basically this means water the flowers that are blooming. For example, our Investor CRM and Investor Update tools are both on Version 2, whereas our Media CRM tool is still in beta, and our Idea Validation tool is in the middile, at V1. We pace development on each based on customer usage and demand.
6. Streamline — don’t bloat. Make a list of everything that is confusing to users, including on-boarding friction, and work to solve the friction by simplifying the product. Prune features that aren’t used. Seek to remove steps in the process whenever possible. It’s addition by subtraction.
7. Test, measure, and cull the herd.Be bold, and kill off products and features that aren’t working, that no one is using, or that distract from your master vision. **To note, this is our plan, but we haven’t killed anything off — yet; I very much look forward to the day we kill off our first product. :)

Bottom line, a multi-product strategy can work. Plus, there are advantages:

More opportunity to uncover “hits.”
Even with lean development methods and tons of customer interviews, it’s not always possible to discover what people really want without building something first. Thus, creating multiple products increases the odds that you’ll discover something innovative. Put another way, more shots on goal = more overall goals.

More cross-selling opportunities.
This one is pretty obvious, but if you have a string of related or connected products, it’s easier to cross-promote and upsell. In our case, companies that have used our Getting Started templates will probably soon be candidates for our Investor Search tool; similary, companies that have used Investor CRM would be relevant for the Investor Update tool, and so on. The online video game industry does this sort of cross-promotion so well — but it applies equally well to SaaS companies.

More marketing angles.
Related, multiple products means you have more “bait” to put in your online fish traps. For example, we are planning to build separate landing pages around each product, create content around each page to boost SEO, and then use these subdomains to drive new visitors back to the main “store.”

More perceived value.
Many users have told us they would pay the $29 or $59 just for the Investor CRM alone — but as a “bonus” they get all these other tools as well, which increases customer delight. Whether they use them or not is somewhat irrelevant — the perception of getting a lot of value for the money creates satisfaction.

At the end of the day, is this somewhat contrarian “platform” approach the right way to do things? Only time will tell. I had a VC recently turn me down because of what he felt was a lack of focus.

He could be right. But our 5,000 users — and the feedback they are giving us (“I’m loving X, can’t wait to use Y”) — and their increasingly frequent credit card swipes — are telling me a different story.

And ultimately, that’s all I care about.