Why we don't do pro services anymore

One of the big shifts that's happened this year at KnowledgeOwl is that we have quietly removed our professional services (pro services) function.

This seemingly small change actually represents a much bigger change behind the scenes, so I wanted to talk a bit more about it.

But first, some background

KnowledgeOwl has existed in some form or another since 2014, when we started life as HelpGizmo (HG). HG was originally a passion project at SurveyGizmo (now Alchemer), starting as a knowledge base but it was supposed to grow into a full-fledged help ticketing system. Instead, SurveyGizmo decided to pull the plug on the project and offered it for sale to Marybeth and Pete, our beloved cofounders. They bought it, rebranded it to KnowledgeOwl (KO), and decided to go all-in on being a standalone knowledge base software.

Both Pete and Marybeth came to KO having done software support, and so support has always been baked into KO's DNA.

Much of KnowledgeOwl was built to be highly customizable. We used that customizability ourselves to add small features and functionality where they didn't exist. Many of our early customers got a lot of one-off bespoke customizations this way.

Over time, those one-off customizations started to consume a lot of our work and time, and we realized that we couldn't keep doing them for free. So our official Professional Services (pro services) function was born. Any customer could contract with us for one-off customizations, and we even included complimentary pro services in our original enterprise level plan.

Some more recent background

Having a proper pro services function helped us in many ways: it cleared out our "normal" support queue of these complicated setups, it allowed us to have dedicated owls to manage and build those pro services, and it gave us an additional revenue stream (and what small company doesn't like that?).

But almost from the moment it was born, pro services caused us troubles.

Simple theme builds turned into wildly complicated Frankensteins over time; customers sometimes had us build things that made built-in KnowledgeOwl functionality not work, or their customizations prevented them from using new features as they came out. Maintaining pro services as we updated KnowledgeOwl also became a chore.

We quickly realized that complimentary pro services for our enterprise customers was creating an ever-expanding backlog of work, so our first iteration on this was to adjust our enterprise plan to be discounted pro services rather than complimentary. That relieved a little of the pressure, but not enough.

We also noticed trends where several customers requested the same kind of service repeatedly. On the one hand, this helped us somewhat "standardize" those offerings, but on the other, these were potential feature candidates that we basically never added to KnowledgeOwl itself because we kept getting extra money to add them in customized ways.

The pro services work was also relegated to only a few owls, and we had some serious knowledge transfer problems after we had some turnover.

It was clear that we couldn't keep doing pro services as a separate silo, but the turnover also required us to ask ourselves: do we still want to offer pro services at all?

At first, we said yes, we did still want to offer it, because it felt bad to say no when people asked us for help.

But over time, it became clear that this old model no longer worked for us.

And after much internal discussion and debate, we came to the conclusion: pro services needed to go.

Why we removed pro services

There are a variety of reasons why we decided to make the change. I believe most of them stem from a fairly simple realization:

Every hour we spent doing a paid pro service for an individual customer was an hour we lost that we could have been building a feature to benefit all customers.

We had to embrace what it meant to be a bootstrapped SaaS company with a single product and to make that product the best it possibly could be.

We had to stop bandaiding the product's weaknesses. It needed to succeed on its own merits, and we needed to surface all of the ways that pro services had been hiding some of its flaws from us.

We also needed to stop dividing our time. We had to stop being both a service and a product company, commit to one, and move forward.

So we chose: we're a product company.

We build one thing: knowledge base software called KnowledgeOwl.

We don't want to build a small secondary parliament of additional owls building customizations; we want to build KnowledgeOwl.

What this means

The only customers who really saw changes to things were some of our enterprise folks who joined us when complimentary pro services was part of the package. We've handled these conversations both informally directly with these customers and formally as their subscriptions come up for renewal.

For our enterprise customers, we've opted to replace pro services with what, for lack of a better word, we might call "success services". We've hired two lead success owls and a big part of their role will be regularly scheduled check-ins and account management with these enterprise customers, and we're exploring offering additional training or other services that still give this tier of customer a higher service experience, but as a pure service rather than a service that supplants the product.

For our non-enterprise customers--particularly those who never knew pro services never existed--this change probably means very little.

Except behind the scenes, it does. 😊

Here's how:

1. 🔍 Better focus.
   Without the distraction of building new or maintaining existing pro services, our owls are better able to focus on support requests from all customers. It's easier for us to share knowledge across our entire Support and Success teams. We don't have to worry as much about the one person who built x for customer y being unavailable. (Though we do still have this with some of our longstanding customers, who started with us back when we did do a lot of customization!)
   
   
2. 📈 We've built more features.
   Most of the pro services that we built repeatedly are now finding their way into the product as fully-supported features. Article Favorites and Required Reading are both former pro services that we've standardized and improved on as we moved them into KnowledgeOwl. And even when we haven't done this, freeing up some of our more technical resources means that we're thinking more creatively and longer-term about the feature set we work on.
   
   
3. 🙊 We do say no to requests.
   Thankfully, we don't have to do this often, but it does happen! Without the emergency parachute of pro services being able to save us from a missing feature or a complex theming request, we have to be really clear about how and what we choose to work on. This means that we sometimes say no to things. That "no" might include suggesting a partial workaround using KO or a shift to an alternative tool that may be a better fit. A huge part of my role as Chief Product Owl is simply this: saying no to a lot of things, and yes to a few. The good of the many (our entire customer base) has to be improved by the changes we make.
   
   
4. 💁‍♀️ We allow customers to sponsor a feature.
   When a customer sponsors a feature, they're basically paying us to prioritize that feature. This means that if there's a feature their organization really needs--and it's a feature we'd like to build but don't have planned anytime soon--they can expedite it. We build it as a fully-supported, fully-included feature that is available to all of our customers, not just the sponsor, and that feature will evolve over time based on all customers' needs, not just the sponsor's. This sidesteps concerns we had about pro services customers "capturing" our roadmap: we handle a very small number of sponsored features each quarter and features must meet a variety of criteria to be considered for sponsorship. So far, this seems to be a good compromise between our desire to be responsive and helpful to every customer and our desire to build a really solid product.
   
   
5. 🎁 Offering new/different services directly or via partnerships.
   As we wind down the support needs of our previous model, we're exploring ways to offer other services more aligned with our current goals. This includes services we ourselves may want to offer (such as regular check-ins with our enterprise customers or additional live or recorded training and orientation sessions), as well as partnerships with like-minded organizations who ARE services companies that provide services we think our customers would find meaningful, like theme builds, migration services, custom development, and so on. We're still exploring this space but we love the idea of partnering with companies who are better at some of these services than we ever were, while also intentionally exploring services that we are very good at.
   
   
6. 🌠 A renewed focus and vision for what we're best at.
   These decisions have been paired with a lot of soul-searching around who we are, what we offer, and what problems customers use us to solve. This larger perspective and understanding of ourselves and our value in the world is causing some shifts in our roadmap and priorities. The next few years will likely see us laying the groundwork for lots of changes, some of which will reel back some of the heavy customization we've supported in favor of building a more user-friendly/no-code-required product to work with. (And I'll continue to share blog posts as we better define and articulate these goals!)

Final thoughts

As I think about these changes, there's really two ideas I keep returning to, again and again.

The first is an idea I owe to Herb Caudill, founder and CEO of DevResults (and my former boss), in a talk he gave about international development at MERL Tech 2015 (the diagram I'm thinking of is around the 5:30 mark):

In order to make the world a better place, imagine a Venn diagram. One circle holds all the world's problems. The second holds what you're good at. The tiny sliver where those two things overlap is where you should focus your efforts.

We were okay at doing pro services, but people could just as easily hire outside developers to do a lot of what we did there. What we are uniquely good at is creating and building knowledge base software that is purpose-built, intuitive, and doesn't require developers to use. We want to focus our efforts on that.

The second is just the idea of focus: it's hard to choose to focus your time when you're torn between conflicting priorities or goals. By dropping pro services and pursuing partnerships to help fill that void, our team can focus 100% of our energies on creating, maintaining, improving, and supporting KnowledgeOwl. By bringing all of this functionality fully within KnowledgeOwl, we can guarantee its reliability and evolution over time. And by keeping our focus, we can work on more complex features or getting smaller features delivered faster.

That should mean:

• More and/or larger new features
• Upcoming redesigns of areas that have always felt a bit confusing
• Small delightful enhancements or Easter eggs that we can slip in
• Partnerships with organizations that can offer what we did in pro services except better, faster, and/or enjoying it more than we did
• A product that continues to evolve and grow to meet our customers' knowledge management needs

Pro services is dead; long live KnowledgeOwl!