Congratulations, You’re a Technology Company Now
Startup founders and companies giving software as a service (SaaS) a shot for the first time share an infectious optimism about their big idea. That belief spills over into planning, and — more often than not — all funding and resources are thrown straight into application development. It’ll change the world, after all. Why not build the best thing possible?
Change is within reach, but it requires a steady hand in resource allocation.
Redirecting the momentum around the big idea is a big part of sales and discovery for a software consultant, which is a nice way of saying that I’m often acting as a wet blanket. We’re well-practiced in several early-project speeches, including greatest hits like:
- Building it isn’t the same as marketing it
- Your requirements will change once it’s in front of customers
- Congratulations, you’re a technology company now
They’re all important, but that last one is a pit of commitment and responsibility that’s especially sobering for nontechnical founders. Let’s take a look at its impact and the places where a post-launch budget is vital.
Your Pledge to Customers
You offer a service, but responsibility doesn’t begin and end with access to it. Customers (particularly ones that pay) create a set of needs that center around communication.
Handling Support Requests
When there’s an issue — and there will be — users need an avenue to tell someone.
That doesn’t mean you should start prepping a call center for launch day, but a process has to be present. Where do support requests go? How are they routed to the appropriate person from there? Who gets informed when there’s a fix? For many, this means setting up a third-party service like Zendesk and a schedule to keep an eye on it.
Early on, everyone will be pitching in to answer support messages. It’ll feel like a chore, and it’ll sound like a chore (from the chorus of groans when it’s brought up), but it really shouldn’t be. Covering support requests is the easiest way to talk directly with real, live folks that have chosen to pay for your service. There’s insight to be had from those discussions. And, it’s amazing how many customers become loyal fans after being helped by the founder.
We’ve lived the crush during free-of-charge Code School weekends, where we’d entice volunteers from every team to help out with promises of pizza. Basecamp has long held a stance that everyone should pitch in, too. The process that’ll fit (and the timing to hire dedicated customer service reps) varies from product to product, but it can’t be put off without losing some early adopters.
Managing Feature Requests
Early product releases are a flurry of iteration and discarded roadmaps.
You’re certain to hear feedback from users that sounds a lot like: “This would be perfect if it just had _____.” Saying no isn’t too difficult if you hear a request once, but what happens when you hear it daily? What if a huge organization needs one bit of customization before they can commit or renew?
Past the fanfare of launch, customers are owed a reasonable amount of future insight on the product they’re paying for. Release notes, maintenance windows, version schedules, and roadmaps (that aren’t discarded) all become part of the technology company reality.
Policies for Everything
Everything around customer communication, including the support and feature requests we’ve been talking about, leads to the need for set policies. They’re not there to hide behind; they’re about documenting consistent expectations for everyone.
How do refunds work? What’s the baseline of monthly uptime? How do you moderate community-driven features? Predictability is the name of the game for the more contentious areas of the business, and determining those answers ahead of time is a much better look than making it up on the fly.
Your Pledge to Technology
As a technology company, it stands to reason that you’ll be putting a fair amount of ongoing effort into the technology part of your product. Let’s run through the areas that’ll wind up demanding the most attention.
Maintenance = Upgrades
First up will be management of all the frameworks, languages, libraries, packages, and third-party services that make up your application. As I pointed out with licensing, the count can easily jump into the hundreds or thousands. These dependencies are constantly receiving updates of their own, which’ll include bug fixes, performance improvements, critical security patches, and features that you’ll want reflected in your product too.
Third-party services come with the added danger that they can up and disappear one day. SublimeVideo (no link, which means exactly what you think it does) was a paid video player service that we used in a few projects and across all Code School courses. As it shuttered, we had to devote unplanned time towards finding, replacing, and redeploying all of the offending materials.
The Shelf Life of Software
Browsers have stabilized a lot in the last ten to fifteen years, so there’s less of a danger (than there used to be) that today’s web standards will suddenly stop working in the near future.
The bigger concern sits with quality and competitor creep. Resting on laurels stuff. Applications at the forefront of design and experience five years ago feel dated today, and competitors will routinely pop up with a fresh attempt at improving your offering.
When we switched internally from HipChat to Slack in 2013, I was relatively annoyed. The latter didn’t feel like a huge upgrade for the trouble, and it lacked the backing of a company like Atlassian. Slack was certainly prettier and easier to use, though, and put the right polish on the right features as it stormed the market. In 2018, to really put an exclamation point on it, Slack would go on to purchase (read: shut down) HipChat.
Kicking off a new venture with a full in-house team to support it is rare. Staff developers may exist, but there are usually specialization gaps until the project gets its feet. Technology companies (that’s you!) can fill the gaps and get a serious jumpstart with the right vendor, skipping the recruiting and managing of an array of roles.
Even if it never makes sense to bring a development team together on your payroll, a technology company needs someone comfortable wearing the CTO hat for longer-term platform vision and decision-making.
There’s an Upside, Too
Being a technology company isn’t all bad. Its popularity would be really confusing, if that were the case. As a refresher, let’s end on the key benefits this path imparts.
Building out a product unlocks the wonders of scalability. Most products start with a service that requires one-on-one meetings, a brick ‘n’ mortar location, or manual intervention. Software automates that limitation away. Some of that custom, human touch is lost, but the result can ramp with revenue and reach in a completely new way.
Our work on Explore Data Science walked that path. As the data science specialty came into being, Booz Allen Hamilton lacked a scalable means of training internally for the role. Diving into educational technology fit the bill, with the added benefit of centralizing and standardizing their curriculum.
A New Audience
As the internet melts (most) boundaries away, the globe becomes your marketplace. Who knows, maybe you’ll be big in Japan.
Attention for Whatever You Were Already Doing
Engineering as marketing is a means of promoting your existing services through a product or tool that gains a following of its own.
We didn’t plan for it, but our Code School association was our primary means of leads for years. Companies wanted their own technical training platform. Organizations heard of us through their developers, who in turn learned their trade on our platform. It’s a much riskier marketing avenue than your standard ad spend, but it carries so much potential.
Welcome to the Club
Whether it’s a customer-facing product or an internal tool to clean up a process, launching an application means that you’re now a certified technology company. It’s an exciting line to cross (scale! audience!), but there are some new responsibilities that come with the territory.
We talk with founders and embedded teams looking to take the leap all the time. If you have any questions, I’d love to chat.
10 years have passed since Rails for Zombies and though EdTech is constantly evolving, there are still lessons to learn. Find out more.