File not found

FAQ Friday – Consulting vs. Product

Welcome to our latest FAQ Friday, where industry experts answer your burning technology and startup questions. We’ve gathered top Minnesota authorities on topics from software development to accounting to talent acquisition and everything in between. Check in each week, and submit your questions here.

This week’s FAQ Friday is sponsored by Fulcrum. Fulcrum helps mid-sized production shops bring their workflow into the future through flexible software that creates a connected supply chain, reduces time-intensive data entry, and increases the overall speed of a company’s entire network.

Meet Our FAQ Expert

Yu Sunny Han, Founder & CEO at fulcrum | @sunnythehan

As the CEO and Founder of fulcrum, Sunny is dedicated to delivering a connected future where frictionless manufacturing production and supply chains lead to faster and better product innovations.

This Week’s FAQ Topic – Consulting vs. Product

What are some differences between consulting and product work?

Consulting work is like being a blacksmith. You have some specialities and a wide range of capabilities to build whatever the client wants. You have the knowledge to help them come up with ideas of what they want and to navigate the process of building it, testing it, and getting it up and running. You’re working to deploy it quickly and you’re celebrating when no maintenance is needed for many years of successful operation. Consulting projects can deliver lots of very specific value very quickly but can end up evolving into complicated webs of changing priorities, different project managers, and a lineage of disconnected developers.

Product work is complex and future focused. For every ounce of excitement over the coolness of what you’re building is two ounces of anxiety that it’s not the right thing. You’re figuring out how to build at scale and mass produce. In product work, you’re considering the stepping stones that get you to your long term product goals. You may make tradeoffs now that help you achieve a longer term goal: forgoing new features to work on an infrastructure change that no customers see, but improves the long term sustainability of the product. You’re also extremely protective of the product roadmap and features, and highly anchored in the why for every decision.

Client excitement and delight derives from managing the client relationship, internal politics, and selling the final result. There’s a lot of emphasis on solving political pain as much as functional pain.Your success relies heavily on the perceptions of a few key people. It’s critical to understand your main stakeholders and ensure that you can consistently manage their expectations and emotions. 

When building a product, your objective is to guide the customer through the existing software most effectively. Customer expectations are clear – what you see is what you get. Since future features are not expected, customers are excited and even delighted when they find out new functionality is coming. Since your time isn’t the primary factor in customer interaction, there’s more reason and opportunity to talk to end users. Large, cool things can be built and have the costs spread out across many customers. 

Consulting work is a direct pay for service relationship. You’re relying heavily on personal relationships, and continuously selling to stay alive, making it difficult to achieve economies of scale. Meaning when you stop, revenue stops.

In product, LTV and forecasting is a complex mix of projecting future deal volume, close rates, customer acquisition costs (CAC), and recurring revenue based on the product decisions and pricing decisions you’re making today.

We have a customer that’s asking for services but we’re not set up to be a consulting firm. Should we handle this ourselves or hire an outside consulting company?

If the customer is willing to pay you for services that you would otherwise have to do, you should definitely do it and learn to do it well. If you’re encountering this, you’re likely working with larger enterprise customers already. In those deals, it’s not uncommon for the customer to expect to pay 25-50% of first year subscription fees in implementation and customization services. If you don’t have an implementation or customer success team built out, you’re also likely just tipping upmarket and/or early on in your product development. 

Either way, this gives you a greater sense of the politics, complexities, and power dynamics in implementing your software. If this gives you anxiety and is the reason why you don’t want to do it, that’s okay. That anxiety is both accurate and also a resounding reason to do it. Your software is only valuable if people are using it to the fullest extent possible. This type of work will help you make better product decisions and give you ideas for automation that will help your customers and yourself to scale and deploy faster. Anything that accelerates time to value delivery is something worth doing. Getting paid to do it? Even better.

Beware, as this can also be a slippery slope. It’s possible to engineer yourself into a corner when the primary value is delivered through customizations and not through the product. While certainly a way to create a profitable business, you may have unintentionally paved the way for a technology-enabled services company, and you will have become the consulting firm that you are currently debating whether or not to outsource to.

We’re a startup with a product idea. We’ve gotten some funding from friends and family but we’re out of runway and it’s not looking like we can raise more capital. We have some opportunities to do consulting work but we don’t want it to be a distraction, how do you do consulting work but still stay focused on the product?

Products are hard to build. They take time to return capital, and you’re going to make plenty of mistakes. Consulting can be a slippery slope: you’re going from building the right thing to building what your client wants. If the pain is big enough for your product to succeed, it’s big enough for some subset of companies to want to solve it through expensive, unscalable, custom software development. If you’re early on and your costs are low, all of the following should be an option for you:

  • Sell a custom version of your product to a customer at rates significantly below market value. Since you don’t have to pay for expensive sales teams, offices, and employees, you should be able to offer the same deliverable for 1/3 the cost. 
  • Do work that is related to but not exactly the problem you’re looking to solve. Early on, we wrote accounting integrations between CRMs, built custom reports, and digitized custom quoting sheets. None of this work was in our core product or on our roadmap, but we did it within the same industry cheaper, faster, and with more domain knowledge than other software shops. This work gave us insights on how we could adapt our own software to better fit the industry.
  • Do other work that is not related to the problem you’re solving but still within the same network. In our scrappiest months, we built websites, managed digital marketing, created master budgets in Excel, etc. While this work wasn’t related to anything we were doing for our customers in our product, it still allowed us to get our foot in the door.

There’s no shame that you’re in this position. Some products are harder to build, some ideas require more polishing, and some startups need to pivot one more time. If you can persevere, good things will eventually happen. Consulting isn’t scalable: you’re trading hours for dollars. Let yourself live in that paradox, and you’ll improve the odds that the consulting work is a pit stop and not a destination.

How do you make the shift from a consulting culture to a product culture? We have a thriving consulting business and we have an incredibly talented team but it’s been really hard to get our product idea off the ground.

There’s a big change in mentality and internal reward systems when you make this shift. When you’re working on consulting projects, billable hours are tracked, budgets are managed, and change orders are communicated with the client. Teams are smaller, budget is reserved for changing the color of buttons, and everything is a sortable grid. The scope and budget are limited, making money is about efficient, ruthlessly bargain hunting against a changing landscape. 

Over time, you start to suppress the urge to create that new feature that the customer didn’t ask for and the sales team doesn’t want to sell. Over time, you learned to savor the small victories, the immediate stories and accolades. Your culture revolves around celebrating on time, on budget deliveries fueled by keen analysis and making the best short and mid term decisions. There’s nothing wrong with this, but these creative instincts aren’t easy to restore.

Building a product is building what you believe is right. You have that the right answer exists, even if customers disagree. Getting to the point of understanding things at the level of core principles and suppressing the urge to seek immediate approval is incredibly challenging for anyone. Doing it while you also have great margins and cash flow from clients who are constantly validating and approving your work? That makes it excruciatingly painful. Every bit of this cultural switch is as psychological as it is organizational or technical. 

What’s required is broader, stronger leadership. Someone needs to provide the vision and clarity to rigorously prioritize work. This will result in disagreements, which is natural and expected. Decisions are uncertain, chaotic and involve multiple answers to questions that are known, and will cause anxiety regarding questions that are unknown. There are infinite variables, infinite answers. Choices made now are going to be wrong, often requiring rewrites, causing psychological pain from years of negative reinforcement. If the entire company is set up to assist and guide customers based on their special, unique, specific circumstances, it will be insurmountably overwhelming if no one is willing to step up and take responsibility for the vision, and also the failures, of building a product.

This seems daunting but the process is simple: set a clear, albeit uncertain, vision, take a series of little bets, ship often, measure the outcome, reward victories and don’t punish failures.

Still have questions? Ask Sunny questions on sales and more on Twitter at @sunnythehan.

Jac Stark
Jac is a self-proclaimed MN tech and startup hype girl and has a knack for curating Twin Cities outings.