Hi, I'm Nelson Joyce, a product designer and cofounder of Tettra. I've been designing and building B2B SaaS products since 2010.
Tettra is a communication tool for teams to document processes, projects, and knowledge. Most work tools like chat, project management, and email are quick and transactional. Tettra is built for sharing information that requires a deeper and more well thought out write up like product specs or company-wide updates.
Making information available to your team allows them to make better decisions, since they have more context. You can think of it like a new take on a traditional company wiki.
We're about two years in, have just north of 300 customers, and are making $23,844 in monthly recurring revenue at the time I'm writing this.
Before we started Tettra, my co-founder Andy and I worked on a "secret project" inside of a large public company called HubSpot. It was just the two of us working on this project for over a year, and we built up a ton of knowledge that was trapped in our heads.
Once our product started to get some traction, our bosses decided to add more people to our team. Since we had been so secretive with our project, it was extremely painful trying to communicate all this built-up knowledge to our new team members.
Anticipating having to do the same thing with new teammates, we looked for a simple knowledge base tool for sharing all that knowledge. We didn't find one that worked the way we wanted, so we decided to leave HubSpot and build our own instead.
Since HubSpot had gone public a few years earlier, we were able to sell some of the stock and self-fund the company for the first six months.
Despite the fact that my co-founder and I are both technical, we didn't go straight into building. We spent about six weeks on initial customer interviews before writing a single line of code.
As far as finding people to interview, we posted to our personal networks and did some good old cold outreach. Here's a more in-depth post about those strategies that I wrote.
Once we got folks into interviews, we asked about pain points around sharing internal information, specifically involving current wiki and documentation solutions. Here are some tips I wrote up for interview questions to ask.
Based on that research, we were able to spend November of 2015 building a prototype that we could get some people using ASAP. We actually just forked a WordPress plugin called P2 and made some modifications for the initial beta users. This wasn't a perfect production environment that we planned on scaling to thousands of users; it was a simple WPEngine setup just to get the product into the hands of a few beta users to start learning.
The bad news was that once we rolled out that initial prototype, no one ended up engaging with it. The good news was that we only spent a few weeks building something instead of months. Coincidently, during the time we went back to the drawing board, Slack released their new platform ecosystem. When I looked back at all the initial research we did, I noticed that every team we talked to used and loved Slack.
We decided to make the switch and spent the two weeks around Christmas and New Years rebuilding a brand new prototype built 100% to work with Slack. Once we launched the new Slack prototype to the public in the first week of January, we had hundreds of people sign up in the first few days. This was the validation we needed to double down on this Slack-first approach. Here's a post where you can read more details about that process and the results.
At this point we decided that in order to capture all this new demand around the Slack platform, we needed to increase our development speed. The problem was that we were almost out of the money we had put into the business. We either had to do contract work or try to raise a small angel round to fund continued development.
The angel round allowed us to hire a full-time engineer and rebuild the product (yet again!) to create a scalable platform for future development. We chose to build the product on Laravel since there's so much already built in to get you up and running quickly and simply. For more details about the nitty gritty of getting the round done in only a few months, check out this podcast episode.
We spent March and April building this new version on the Slack platform and signed up our first paying customer on May 10, 2016.
So from start to first customer it took us a little over seven months of learning and iteration.
We publicly launched the new product in May of 2016 with a Medium post announcing the "public beta" and our funding.
That post immediately got picked up by the local tech publication Bostinno.
We did a brainstorming session around all the channels we could try out and followed the Bullseye framework to prioritize a few of them. Here's the actual Tettra page where we did the brainstorming.
We did the typical sharing to all social networks (Linkedin, Facebook, Twitter, etc.).
Prior to launch, we posted on Betalist and had about 65 people on a waiting list. We also posted to all the typical directories like Stackshare, Siftery, Capterra, and Alternativeto. As you can see in the chart below, only Betalist and Alternativeto ended up driving any significant traffic.
We decided to wait to post on Product Hunt until the product was more fleshed out and our sales funnel was working on a small scale. We ended up launching on Product Hunt about six months later and got over 700 upvotes and was the #3 spot for that day. Here's the actual Tettra page we used to plan the Product Hunt launch.
The Slack Platform
Of course another massive source of trials was the Slack App Directory. After our experience, I highly recommend launching on a platform like Slack, WordPress, or Shopify.
There's a whole chunk of functionality that you can essentially "outsource" to the platform. For us, that was authentication, user management, and access to the "work graph". You also get free distribution from the parent platform and a clear target persona you can attract.
There are definitely risks involved, but the benefits outweighed the risks in our eyes. Here you can check out more details on why you should launch on a platform from my co-founder Andy.
"Emerging" Keywords
We were also lucky enough to jump on the "Slack Wiki" keyword pretty early on an ranked in the top few slots from the get go. There wasn't much competition for that term at the time, and we've been able to maintain the top non-branded Google result for that. All we did was put the term "Slack Wiki" in our website title tags and headers, and that was good enough to rank for a new term.
Results
These are the traffic sources between May 1 and July 31 to tettra.co after launch. As you can see, most of the traffic came from Google and Slack. Those top two channels make up about 50% of the trials as well.
Bottom of the funnel
Once we got people signed up for a trial, we got as many of them on a screen share as possible to walk them through the product and collected their credit card info right on the phone.
We tried to continue to scale a demo-based inside sales playbook, but after a lot of pushing, we couldn't get it to work. The problem was that the product was simple enough and we were selling to small enough teams that they just wanted to start using the product right way and didn't want to do demos. It was a great way to get the machine going initially, but it just didn't scale for us.
Our strategy now is to sell "touchlessly" with emails, getting started resources, and chat support. We're still in the early stages of this transition, so I'll have to report back on the forum with the data once we see the results.
We launched the initial product with no billing integration at all — we just collected credit cards over the phone with customers and entered them manually into Stripe. There was nothing preventing anyone from going to app.tettra.co and using the product without paying. But no-one did of course. It saved us a few days of dev time and allowed us to start selling right away.
Since then, we've tested a bunch of different pricing models.
We started with $5 per user per month. The rationale was that it was the same mechanism but a smaller amount than Slack's pricing. We ended up switching the pricing to flat "bundles" of users due to customer feedback. We also were seeing that it took months for folks to add their team members, so we were only collecting $5-15 dollars in the first few months of a new customer.
When we changed to the flat pricing, we saw a big bump in average sales price. We started making more money by doing less work, which was a win-win.
We tried to increase the prices a second time, and while we still saw customer signups, the trial numbers were way down. You end up trading the higher revenue for fewer customers, so we decided we wanted to be lower on the spectrum to attract the appropriately sized customer.
Currently, we use a lower "base" price based on features (starts at $60/mo) and have a second axis of pricing around user bundles. We think it's a good balance between not being too intimidating to start and the ability for a customer account to grow as they use the product more over time.
The hard thing about pricing is that you can't really A/B test it, so it takes a long time to see the results of a change. Even with a 15-day free trial, it still takes us 6-8 weeks to see the full effect of any change.
My advice would be to keep gradually increasing the price over time until you see your signups drop off to a point where you're uncomfortable. Then lower the prices to just below that point.
Our next big milestone is getting to profitability. We project that we'll get there by Q2 of next year.
Beyond profitability, getting to 1 million ARR would be a great accomplishment that we think we can reach. Increasing top of the funnel traffic, optimizations throughout the onboarding funnel, and revenue growth from our existing customer base should all combine to help get us there.
Our biggest roadblock right now is acquisition (shocking, I know). Driving enough of the right type of person to your product or service is always tricky business.
Another challenge I foresee is learning how to run a profitable company. Everywhere I've worked in the past has followed the typical "hypergrowth" startup strategy which entails running at a loss using massive amounts of VC funding. There's nothing wrong with that approach, it just takes a different kind of mindset to be successful.
We're pretty bullish on the IndieVC model that Bryce Roberts is working on, so I'm excited to learn more from folks like him in this community.
Our biggest mistake was trying to do too much at once, which manifested in us raising our burn rate too high. (We've since lowered it.) This is such a common mistake I'm almost embarrassed to admit it.
One of the downsides of raising money is the false sense of security you get. This caused us to try to sell to too many target customers with both a sales-driven and product-driven model. This pulled us in too many directions.
Focus on one use case for one target user with one go-to-market strategy. This is even more important for small, resource-strapped companies.
Sleep. Seriously, getting a good night's sleep is my top "hack" for staying happy and productive.
Don't burn yourself out. I see a lot of founders and tech folks grind themselves to the bone to get more done. In reality, those extra hours are probably hurting your productivity in the long run. When you're working, work hard, but when you're home, rest your body and mind to tackle what lies ahead.
Everything takes longer to get right than you think. Not much you can do to about this except to stay positive and patient! A lot of products win simply because they don't get acquired and/or shut down.
Learn about pricing. One of the highest leverage changes you can make for your business is a proper pricing strategy. I highly recommend reading everything written by Patrick Campbell at PriceIntelligently — specifically the SaaS pricing eBook. It took us too long to get this right (and there's still room for improvement!).
Learn about "market/product/channel/model fit". Most people focus on the integration between products and markets (aka product market fit), but this concept by Brian Balfour has been transformational for how I understand software businesses.
Acquisition will probably be your biggest challenge. Everyone underestimates the difficulty of acquiring customers, especially us hacker types. Almost all great companies win due to distribution advantages.
If you're interested in improving communication and transparency on your team, give Tettra a try and let us know what you think. Happy to answer any questions in the comments below or on Twitter as well.
Bonus if you've made it this far: Mention this post to us and we'll give you 20% off your subscription for the first three months.