Life is pretty simple when your product is relatively new and you have only a handful of users.
Want to deploy a new feature to your user base? Release it and test it live in a production environment.
Need to move servers and take the site down for 20 minutes? Just do it in the middle of a Wednesday afternoon. If one or two people email, tell them it will be back up shortly.
This is what our life was like about a year ago after a 17 month grind to reach product-market fit.
Now life is different. As of this writing we have 1,273 paying customers and 2,637 free users. We also have a small but growing team of eight, including me and my co-founder, Kevin.
As a mid-stage SaaS company we need to be strategic about how we plan, design, test and release our software. Statistically speaking, if one customer complains about a problem there are likely 26 others experiencing the same problem and not saying a word.
We’ve written before about the power of plain language, but for a concrete example of how important it is, especially at scale, check out what Derek Sivers wrote about how at his last company he had 2 million customers:
“When writing an email to everyone, if I wasn't perfectly clear, I'd get 20,000 confused replies, which would take my staff all week to reply back to each, costing me at least $5000 plus lost morale.”
While we may not have 2 million customers (yet!), I do feel this pain on a smaller scale whenever we publish an update, or when a few months back we were down on Sunday morning. As Alex Turnbull wrote in his post, The 3 Deadliest Challenges of Scaling a Startup:
“With more customers pushing our product to its furthest reaches, bugs and incompatibilities are being found all the time. This isn’t unique to Groove. Every single software founder I’ve discussed this with agrees: more customers means more bugs. And more bugs means less time for our team to work on everything else.”
Mind you, I’m incredibly thrilled to have this problem. Believe me, having too few customers and struggling with traction, let alone growth, is a thousand times worse than having to accommodate a larger customer base. (Basically what I’m saying is, if you use Proposify, I love you.)
In this post I will document the processes we’ve implemented to scale Proposify in the hopes that if you have an early stage startup or even just an initial idea, this can help you as you grow. I’m not saying this process is perfect — it could change next week, but so far this is what’s working for us.
Two week release cycles
In the early days it’s difficult to know how often you should be releasing software. Most of us know the key to reaching product-market fit is rapid iteration — talk to customers, find the gaps in your product, and fill them as quickly as possible.
In practical terms, does that mean pushing code daily? What about larger features that take a long time to build? Should you spend a month writing a feature before pushing anything or release it in smaller chunks to test the base functionality in advance of writing the entire thing?
These are the questions we asked ourselves, and continue to ask. But here’s the process that has been working for well over six months now:
Release a new version of your app every two weeks.
Why two weeks? Well, we found if we pushed a new version every week, our small development team struggled to produce meaningful features that moved the business forward. Lots of time was taken up with bug fixing the previous release and solving customer support issues.
We also experimented with monthly releases, but those release cycles got far too big and bloated. There was too much being released that heavily impacted the code base when we needed to push it live to production.
Finally we settled on this process:
- Monday is customer support and bug fixes from the previous release.
- Wednesday we have a development meeting to discuss the big, important features each developer is working on and any roadblocks or potential challenges relating to it.
- The rest of the week each developer works away at his respective list of features/bugs/tweaks.
We use Sifter as our issue tracker. It’s a simple solution, but that’s what we love about it. Sifter let’s us create new tickets, attach them to a milestone, assign them to a person, assign a priority weight (critical, high, normal, low), and categorize them. Our categories are change/feature request, defects, testing, and usability issue.
Once a developer is finished with his open ticket and has it fixed, he can mark it as resolved with a note that it is fixed either on his local branch, on staging, or production.
When testing a resolved issue, if the issue is still problematic we reopen the ticket and leave a note, or if the issue is tested on staging and it’s no longer a problem, we mark the ticket as closed.
We call this Release Week, and it’s run differently from Week 1.
- Tuesday, all of the issues are merged into a release branch and reviewed by Jonathan, our CTO. He needs time to read the other developers’ (Alex and Geoff) code line by line to ensure he understands how it works and that there is nothing that could conflict with other code. While this is happening, Alex and Geoff work on customer facing issues, like small bug fixes they can immediately push up to production.
- Wednesday, all of the latest code must be on staging so Ricky, our product manager, can run it through the QA process. We freeze any non-critical issues at this point, moving them to the next release cycle so new code isn’t being committed. Our dev meeting that week is focused on existing challenges for the coming release, not new features.
- Saturday, late in the evening, the developer assigned to push that release must take the site down for 15 minutes, back up the database, run migration scripts, and push the code. Afterwards, either my product manager or I will run through a QA checklist to make sure the basics work, like creating a new account and upgrading to a paid plan.
- Monday morning we start all over again.
Customer Support Mondays
At Proposify, we’ve long held the belief that everyone on the team should do support, even if it’s not their primary role. Whether you’re the CEO, marketer, product manager, or developer, support helps helps people better understand the customer, their needs, and how they communicate.
In practice, it can be difficult to make this work, especially when you have a full time customer success agent to lean on. We tried a new process to make this simpler and more straightforward: the Monday after a release, people who don’t normally respond to customers (coders, marketers) jump into our help desk software and spend the whole day answering tickets.
At first I thought I was inflicting pain and misery on the team, but looking through Slack it actually seems to be a great team building exercise.
What does Sondra, our customer happiness specialist do on support Mondays? She reviews our knowledge base and updates the articles with new instructions and screenshots, which becomes a big challenge to maintain as your app and customer base grows.
Meetings are important in any organization, but if they aren’t planned and managed properly they can become a huge time sink.
In larger organizations this can become an expensive problem where people are pulled off important tasks and thrown into a meeting they have no idea the purpose of, or what they’re supposed to be contributing.
People can waste half a day sitting around a boardroom table where a vocal member of staff meanders from one topic to another with no resolution or next steps.
For smaller companies the opposite can be true — people can lock themselves away in silos and rarely come up for air. Decisions get made by individuals without consulting the team or having any process for decision making.
We’re working to make meetings regular, concise, and effective. As our team has grown we decided on four weekly meetings, but not every team member needs to be in every meeting.
We outlined a theme or key purpose for each meeting, a series of questions we need to consider, and at least three takeaways or next steps to make the meeting successful. Each meeting shouldn’t take longer than one hour.
Who attends: CEO, Marketing Manager
Led by: Marketing Manager
Big Lofty Purpose: Attracting the best customers, building trust and converting them into lifelong customers and fans.
What We Talk About:
- Analytics review: What have we learned over the last 30 days?
- Target personas, key messages, and unique value proposition.
- What content are we creating and why?
- Influencer review: who should we building relationships with for content distribution?
- What tests could we run that would increase traffic, conversion, activations, retention or referrals?
Big Lofty Purpose: Create the best product for customers and grow the business.
Who attends: CEO, COO, Product Manager, Customer Success
Led by: Product Manager
What We Talk About:
- What have we learned is most important to customers? (from support emails, surveys, customer development calls, etc.)
- What feature should we implement and what is the purpose of the feature? (drive revenue, improve adoption or frequency of use, increase customer satisfaction)
- What features align with our big vision?
- What isn’t being used that we should trim? Trimming unused features ensures that as new ones are added we don’t create a bloated product.
- How should we prioritize the next 90 days/6 release cycles?
Product management is an art, and a difficult skill to master. It’s very easy to base features on subjective feelings, “What do I want?”, or “Someone asked me for this in the last week.”
One of the challenges of scaling a product is managing the feedback you get every day and turning it into something useful you can use to guide your product development.
Here’s our process for managing customer feedback, deciding on what to implement, and how to prioritize features:
Step 1: Collect Feedback
Customer development is one of the most important tasks for founders and product managers to tackle on a weekly basis. Phone calls, support emails, surveys, and online reviews all help you collect data you can use to improve your product.
We use a Trello board and place cards for each customer request, and then post a link to each support ticket we receive with the same request. This lets us see at a glance how many requests we get for each ticket.
Step 2: Deciding On Features
Collecting feedback is the easy part, but turning it into a 3-12 month roadmap is where things get difficult. Feedback is important, but simply choosing features based on the amount of votes is the wrong way to build a product.
Great products have a vision behind them. Popular requests sometimes need to be deliberately rejected from your roadmap based on your vision.
For example, every now and then people ask us to add a code button in our editor so users can directly edit HTML markup. Most WYSIWYG editors like Wordpress allow you to do that, and many of our proposal app competitors do too. But we never will add this feature.
Why? Because my original vision for Proposify was never to be a Wordpress for proposals, it was to be an experience more comparable with InDesign or Google Docs. That means we want the editing experience to be so smooth and easy that no one would ever want to edit their own code. Changing our big vision based on a handful of requests we receive periodically will not happen.
OK, so then how do we decide on and prioritize feedback?
As I learned listening to Des Traynor from Intercom.io explain in his talk at this year’s StartupFest in Montreal, there are four main reasons you want to build a feature:
- Improve a feature (increase customer satisfaction)
- Get more people to use it (increase % adoption)
- Get people to use it more (increase frequency)
- A new feature to support a new workflow (increase customers/revenue)
"Products don’t become bloated overnight, they get there one weak decision at a time. Unused features slow you down, confuse your users, mess up your marketing, and pile up on top of each other. Good product managers remove them. Great ones say no in the first place."
So for us that means as long as each new feature accomplishes one of these purposes, it’s worth doing. A brand new feature or workflow should be tied directly to an increase in customers or revenue (i.e.: a feature we can charge extra for or expand the market we’re going after.)
Next, we use this chart to map out where the feature lies in relation to how many of our customers use it and how often:
If any feature lies outside of the green or yellow squares, we need to closely consider whether or not to kill it. If it lies in the green, and especially towards the most top right corner, it’s an essential feature and a major part of our product, so we need to give it the most attention.
Using this framework, we assign a score to each item we want to add to the product to help determine where it sits in the priority list and from there decide how complex the feature is to build and how we’ll plan it into the release cycles.
Purpose: How to execute the vision for next release
Who attends: CTO, Developers, Product Manager, CEO
Led by: CTO
What We Talk About:
This meeting is somewhat simpler and more tactical in terms of purpose. People go into the meeting knowing what they are assigned to complete for the next release, and we discuss the following for each developer:
- What big ticket are you working on for next release?
- How will it work, both on the user facing and technical sides?
- What roadblocks are limiting a ticket from being completed?
The narrow scope of this meeting prevents it from devolving into a long, drawn out discussion of long term features or things that don’t immediately impact the next release.
We’re still working on a name for this meeting, and it’s the hardest to define. Everyone on the team, regardless of department, attends this and it’s always how we close out the week on Friday.
Big Lofty Purpose: What big goal are we working towards? How can our culture be improved?
Who attends: Everyone
Led by: CEO
What We Talk About:
This is meant to be a more loose, casual meeting where we sit around, have a drink, and try not to get too into the weeds. We’ve been working hard all week and our brains are fried, so we keep it big picture.
This meeting also opens up the room so people in different departments know what the others are up to and prevents silos:
- What takeaways or action items came out of the meetings this week?
- What did we learn this week?
- What should we be doing differently?
- What are our short and long term goals and have they changed since last week?
This is a new thing we just started implementing so it’s too early to tell the effectiveness of it. It’s meant to help keep everyone focused on what they are accomplishing each day and inform everyone else on the team about what’s going on.
Daily standups happen at the beginning of the day on Slack and everyone posts the following:
- What did I work on or accomplish yesterday?
- What am I working on today?
- Is there anything blocking me from accomplishing it?
That’s it, short and sweet. This will take some discipline to remember to do each day, but the team is on board with it, and we hope it helps us accomplish our goals.
Whether you’re building a software product yourself, have an idea for one, or run a service based business, I hope this window into our ever-evolving processes help you run your own company. The key is to make your process simple, keep the meetings short, regular and scoped properly, and still make time for the learning, doing and dreaming that will help you make your vision a reality.