Published Date: February 2, 2016
Last Updated Date: December 20, 2024
If you run an agency you’ve likely been tempted to build, or have already built, your own software product between client projects. I’ve been there myself — and that’s why Proposify exists today. Here I share how to do it right to avoid failure.
There are great reasons to build an internal product on the side.
It can be a way to learn new technology or flex your creative muscles without clients demanding changes.
It can solve a need in the market and eventually become a profitable business.
Still, many digital agencies who attempt to follow the successful path of Basecamp (agency turned bootstrapped SaaS company) never get their projects off the ground. And even if they do, they give up on them.
There are a few reasons why internal products fail which I’ve written about before. In a nutshell, it comes down to having expectations that don’t fall in line with reality, and not having the resources or the stamina to carry the project out for the long haul.
So if you’re serious about launching a product that could one day become your business, then ignore these steps at your own peril:
1. Spend at least two months validating your idea
You’ve got a great idea for an app. Awesome! It can be tempting to jump in head first and start mocking up your idea or writing the first lines of code.
However, unless this is a fun side project you never expect will see the light of day, there are steps you need to take before embarking on a risky and expensive business endeavor.
You need to validate your idea to make sure you’re solving a real problem for a large, paying market of customers.
How do you go about validating?
For the purposes of example in this blog post, I’m going to use an old idea for an app I had that never went anywhere called Saucr.
Here’s the idea behind Saucr: it’s a way for agency operators to ensure their staff are 80-90% billable, and be able to foresee 90 days in advance if there’s an overflow of work in the schedule. It picks up the overflow, like a saucer. Get it?
This way, you can see over a 90 day period if you have more client work coming in than staff to accommodate it so you can prepare by either subcontracting or hiring new talent. Or, you can also see if there isn’t enough work coming in and you’ll need to either get new business in the door or make layoffs.
Let’s say I was serious about getting this idea off the ground, what would I do next?
Customer development
This is so simple but few people actually do it.
Talk to people.
No matter how good an idea I think Saucr is, I need to remember that it’s only a hypothesis, even if I experience the problem first hand.
Here’s my hypothesis:
I believe that companies that sell project-based work don’t have enough information to make long term decisions.
Operators run into bottlenecks where there are too many projects and they don’t have enough staff to execute them, or they have dry periods coming up where their staff aren’t at least 80% billable.
I believe if operators had a visual way to see 90 days into the future it would help them plan for growth, sales, or downsizing and reduce their risk. I believe they would pay for this solution.
Since my target customers are agencies, the first thing I’d do is start making a list, either in a spreadsheet or CRM, of every agency in my city and find out through LinkedIn who is in charge of overseeing operations.
In a very small company that would likely be the owner, or in a slightly larger company they may have a director of operations.
I’d want to fill my list with 100 contacts and call each of them. If you can’t reach them by phone then leave a voicemail and follow up with an email. This is what my phone script would be:
This script does a few things:
- It lets them know right off the bat that you’re not calling to sell them anything
- You are thinking about something to help them with a problem
- You just want their feedback and they can offer it in whatever way suits them
If they agree to answer the questions, then have them written down and ready to go. If they don’t have time ask them if you can email them the questions and if they will respond.
You want to treat this as a research project to collect data, so don’t start by telling them about your idea. Even if they say they like it, that’s not helpful feedback at this point. It’s only going to bias your data and make it unreliable.
Instead zero in on the problem. This would be my list of questions:
- Do you ever put together projections in advance to determine how many projects are coming in and how many in-house resources you have to fulfill the projects?
- How do you currently calculate your staff hours to and plan the time they need to spend on client projects?
- How far in advance do you plan?
- On a scale of 1-10 how time consuming or difficult is it to put together these plans?
- What problems could arise if you don’t put together this plan?
- Would you pay for a software solution that takes this problem away?
- How much would you pay?
See if you can get anywhere near 100 of these calls. Put each of the answers in a spreadsheet and compare them when you’re done.
Caveat: If you’re building a solution for competing agencies they may be hesitant to offer you any information. This actually happened to me when I was calling local agencies about Proposify.
If you’re building a solution for competing companies, you may want to expand your research to those outside your area and assure them their feedback is confidential.
Create a Lean Canvas
Let’s assume the data you collected backs up your hypothesis: that agency operators want/need a better way to foresee overflow in their employees’ time and they will pay for a solution.
Next, what you’ll want to do is put together a basic business plan. I’m not talking about a long winded, text heavy business plan, just an outline to help you understand what you’re building and why it matters.
If you’ve never heard of Lean Canvas, I’d recommend checking that out, and creating a canvas yourself.
At the very least, write a short paragraph or two under the following headings:
- Pain - Show that you understand your customers pain on a deep level.
- Solution - What is the idea and how do you solve the problem?
- Market - What industry are you targeting and how big is it? Who is your customer persona? How do they buy?
- Business Model - How do you make money? How do you acquire customers?
- Competition - What is the alternative to using your software? It could be a direct competitor, or even another workaround (spreadsheets). What are common rebuttals to using your software?
- Special Sauce - How is your approach to solving the problem unique? What is your unfair advantage?
The validation process is time consuming, and people often skip it and go right to building their idea.
But taking the time upfront now to run a sanity test ensures you are building something that doesn’t exist (or at least exist the way you envision it), people want it and will pay for it, and there’s a big enough market to grow.
2. Hire a dedicated team
Most agencies start internal products the same way. They assign a designer and developer to work on it, and they announce that they’re going to treat it like its own client with its own budget.
What happens eventually? The project loses steam because there isn’t a client holding their hands to the fire, and paying client work pushes it out of the way.
As Paul Boag wrote when he closed down his agency’s internal product, Get Sign Off:
“Part of the problem is that our project managers have targets to invoice each month. Because Get Sign Off wasn’t a paying client it was pushed down the priority list. It wasn’t going to help the project managers meet their targets.”
From my own experience, Proposify was an idea I’d had since 2007. We didn’t start working on it in our agency until around 2011, and by late 2012 it was still vaporware for exactly the same reasons stated above.
It wasn’t until we secured a grant to hire a developer that we were able to get it off the ground.
If your agency is consistently profitable, you can invest your own money into the salary of the person you hire. But it’s a risky move if you get into a situation where you need to use that profit you set aside to keep from going belly up during lean months.
In our case, getting a grant from ACOA to hire a developer for a year was the best-case scenario. Depending on where you live, there may be similar options through your local government or economic development agency.
If you don’t live in a country, state, or province where government grants are available, you can pitch angel investors for cash to get your idea off the ground. Just make sure you have a solid pitch deck, you understand your market, and you really are committed to working on the product for years.
Whatever financial avenue you choose, there is no substitute for having at least one dedicated developer on the product at all times. Additionally, you should have a product manager, designer, customer support agent, and marketer working on it, but in the early days you will likely be the one wearing all those hats.
3. Launch your MVP in four months or less
MVP stands for Minimal Viable Product. It’s the very first thing you launch to beta users.
Despite what you want to believe, know that the first version of what you launch is going to suck. It will not be good. People will not understand the UI. There will be crippling bugs. But that’s OK.
The biggest danger to a startup is waiting too long to launch. The more time that goes by the less chance you’ll have to succeed, because you won’t be collecting feedback, and if you wait years to launch then the market may move on without you.
I came across this Facebook post on a startup chat recently:
Most of the comments were pretty harsh on this entrepreneur, and rightfully so. He talked about raising money, differentiating, and a lot of other problems.
But the biggest problem was staring him in the face: He didn’t launch anything for 2.5 years and didn’t plan to for another year!
Your product will never be “ready” and it will never be “done”, so just get something out there.
Looking back at what we launched in April 2013, Proposify (or Pitch Perfect as we called it at the time) was a very ugly, clunky product. Nobody would use it for long, let alone pay for it.
It’s embarrassing to look at now, but I’m still glad that we launched it when we did instead of waiting.
Waiting would have meant waiting longer to get feedback from users, which is completely the goal of an MVP. You aren’t taking over the world at this point.
4. Start marketing long before launch day
You should begin marketing your product long before you launch your MVP.
The goal is to start building an email list of people who are interested in your product, so you can build traffic and momentum.
Design a landing page
The first step is to set up a coming soon page that addresses your users’ pain and how your app solves it. Keep it simple, show off a bit of your product’s design and provide a clear call-to-action for them to sign up.
It’s OK if you don’t have the product ready, just collect email addresses from interested people so they can be notified when you launch.
At the beginning you should drive a little bit of paid traffic to the page. The goal isn’t to grow the business at this point, it’s just to build momentum, learn what keywords your audience is using to search, how much the keywords cost, and get an idea of how much volume paid traffic can get you.
Encourage sharing
Pre-launch products have the rare opportunity of building anticipation about something that doesn’t yet exist.
When someone signs up to be notified when you launch, you should encourage them to share the page with their friends, even offering them an incentive of moving higher up the list based on the more they share.
Neil Patel and Hiten Shah are transforming Quicksprout from simply being a blog about online marketing to a software product. When you sign up to Quicksprout they tell you how many people are in front of you and only give you access if you invite five people.
Start blogging and outreach
Get a head start by blogging from day one. Writing helpful content for your ideal customer will help build a rapport and form a relationship with them, earning their trust.
Alex Turnbull candidly shared how he was able to drive significant growth for his startup, Groove, by crafting a thoughtful strategy around his own blog and by guest blogging on other sites.
Ross Simmonds, the blogger and marketer behind the content curation app, Crate, has this advice to share:
“Marketing your product before you’re live is a great way to establish buzz and ensure that your launch is a successful one.
Prior to launch, establish relationships with a few key influencers, bloggers or journalists who will tell your story on launch day. Encourage them to share on their own social channels, check you out on Product Hunt or even write a post about their experience as a beta user. All of these actions can add up to make your product launch successful.”
5. Gather feedback and iterate rapidly
Once your MVP is out there, you should be emailing and calling everyone on your beta list to get their feedback.
The hard part is that when your product is early stage and you don’t have a high volume of users who are pumped about your product, getting feedback is very difficult.
People are busy, and unless your app is solving a big problem for them from day one, getting deep insight will be hard.
So what do you do?
User testing to the rescue!
If you build software for clients you may already have a UX process in place, but UX can be an easy thing to push aside when it’s your own baby.
Even if you get a lot of feedback from users interested in your product, they aren’t going to tell you everything you need to know. That’s why you need to perform user testing and actually watch people using the product.
UserTesting.com is a great option for this, because they’ll source the users for you.
First narrow down what kind of users you want and get at least five users to test.
Tell users where to start and give them a list of actions to perform.
Watch the videos to see where they fumble around or get confused. Make notes of things they say as they are using the product.
Once you’re done, put all the users into a column on a spreadsheet. List the issues they came across as a row. If a user came across that issue, put a score in their cell (1 out of 5).
Total how many users ran into the same issue, so that the issues more users encountered contain a higher score than issues only one or two users experienced.
Here's a link to a sample test spreadsheet
This method may not give you insight into your market or customer persona, but at this stage just getting something in place that people understand and doesn’t break is the most important thing.
You can always build new features but the foundation should be simple and usable, even if it has a long way to go.
Implement other tools
There are two important tools to get into place from the get-go: analytics and customer support.
Customer Support: It should be dead simple for users to offer feedback while they’re in your app. I recommend signing up for Groove and adding their support widget to your app.
This gives you the added benefit of having all your customer support tickets go into one place instead of getting lost in an inbox.
Analytics: In addition to lots of qualitative feedback (emails, surveys), you need some quantitative feedback to learn what users aren’t telling you.
Using a tool like Heap will automatically track every action a user takes so you can analyse it and learn what parts of your product they use the most.
Heap offers 5,000 sessions per month for free, so it’s a good option if you want to keep your costs to a minimum when you don’t have very many users.
Use all the data you collect to iterate rapidly every week or two, adding features and fixes. Then repeat the process until you begin reaching product-market fit.
Creating a product people love and pay for is going to be a marathon, not a sprint. That’s why you need to have a dedicated team building it, and why you need to keep working on it long after it’s launched.
Conclusion
If all of this sounds like a lot of work, it’s because it is.
But if building a successful software business was easy, everyone would do it. The key is to start off on the right foot and be prepared to invest a lot of time and effort on achieving product-market fit, which can take well over a year.
If done right, you can build an internal product to supplement your agency business or even overtake it completely in time. For me it was a long, painful slog that’s been well worth the time and effort.
