Using Expensive Enterprise Software to be More ‘Lean Startup’
Here is an email I received from our Director of Finance recently:
My response?
It’s a small price to pay for a company like ours to make faster iterations.
Ok, I didn’t say that to Phil. I’m not a complete asshole. But I did approve it and reassure him that we were happy with this purchase because it made us more Lean. I bet I can guess what you are thinking… how exactly is spending six figures lean??
For one, Lean Startup is not the same as cost conscious or scrappy. Scrappy is the fact that our office furniture is a collection of discarded, heavily used tables and chairs from other startups; which for the same pile of cash could instead be beautiful and new, untainted by the butts of strangers.
Lean Startup is not about money — in fact, this is NOT an article about ROI through displacement. If that topic interests you, your local Salesforce sales rep would be happy to tell you more.
For the uninitiated, Lean Startup is all about customer discovery and iterative learning. Before we get into how we’ve utilized expensive software to to do that, let me point out a few nuances about our business.
Our business is called Managed by Q. We make it easy to run an office. To do this, we handle a lot of operational complexity and minutiae. Starting out, we did this almost purely with people — but that was never the plan. The concept was to use software and operational process to overcome the ‘death by a thousand cuts’ that makes running an office well so difficult. This means we need more internal tools than your average bear.
I run the Product Operations team at Q. We don’t build proprietary software, but we do create operational leverage for the business by configuring third party tools. What my team does is not historically revered in the early-stage world. It is not the subject of founder blog posts or startup Meetup groups. You don’t hear about people who configure software getting poached by Google.
This stuff isn’t considered sexy, but I’m here to give you the cabaret show and convince you that it is.
So why has someone else’s software given us an unfair advantage in building an operating system for the physical world?
1. Reinvent No Wheels
We use our Salesforce instance as our CRM for Sales and Marketing, but we didn’t stop there. We’ve used it as a foundational framework for wrangling our operational complexity. It is a core system we build on top of and an essential tool we use to ship Product — just like AWS or Django. We’ve used it to facilitate many non-sales job functions with off the shelf resources — either products Salesforce already built (like Service Cloud), or services that extend Salesforce through the AppExchange (like TaskRay for task management or Teckst for SMS).
When we set up our Salesforce instance, we synced some key objects with our internal system. Suddenly, our productivity apps had the leverage of being deeply integrated with all our internal data. We could have built these tools with proprietary software. Instead, we built a proprietary dispatching system that is saving us from having to hire an army of people, and a ratings system to which we owe the feedback loop that allows us to deliver high quality service at dizzying scale.
Using Salesforce in this way isn’t particularly unique to our company, but it is a super common and valuable way to be more Lean. We achieved software customization without having to reinvent the wheel, which means we got to spend more time on software features that were more uncertain and custom to our business, as well as focus on finding out what would happen if we built them. Some companies do not choose this path, and the mistake they are making is far more expensive than what we spend on Salesforce.
2. Prototype Proprietary Software Faster
For sure, configuring parts of Salesforce that were enabled off the shelf was hugely impactful for us. But we didn’t stop there, as many do. We went a step further and taught ourselves a couple of advanced features of Salesforce called Process Builder and Visual Workflows. For simplicity, I’ll collectively call these features ‘Flows.’ Flows allow you to basically draw a flowchart for software automation, but then — the really cool part — you can just Pinocchio the thing and turn it on and the automation flows through your org!
To be clear, this is not simple configuration — not the mere wheels we avoid reinventing. This is bespoke software automation of operational business process, and we’ve built gobs of it in Salesforce. Collectively, hundreds of examples like this add up to a step change of competitive advantage in our effort to handle the hard parts of running an office.
An aside for engineers and product people:Flows are not like Apex, in which you develop on top of Salesforce by writing code. Flows let us build business logic with a drag-and-drop GUI, without needing many things that go along with coding from scratch. Briefly, some of these off-the-shelf offerings comprise:
-- CRUD functions for any object in the system
-- Database migrations
-- Authentication, security, permissions
-- An API via Zapier
This means we got to MVP faster for the products we built with these tools, learning if we even needed something in the first place before building the infrastructure to support it.
Not convinced? Here is a specific anecdote about how we got to MVP faster:
When we were migrating our first City Operations Team function into Salesforce, we did some ‘customer research’ to figure out what it was they wanted. We logged eight feature requests in the two months (!) we spent trying (mostly with our own assumptions) to get it ‘ready’ and win internal approval to switch tools.
With the admission that I spent months trying to ship something, I’ve likely lost every Lean Startup enthusiast reading this post. (please stay tuned!) Better late than never, it dawned on me how quickly changes could be made, and I used all my political capital to get it pushed out prematurely. What happened? We screwed up a few important things with real, EXTERNAL customers that week, and on top of that, all of our Account Managers had to stay late every day to address it. Pretty much EVERYONE was mad at me…
What else happened?
We got 68 feature requests that week. My team built 49 of them, including every single high priority one and all but two of the medium priority ones. We went from an average of one feature request per week for two months, to getting 68 in a single week.
We only got them by diving in head first, embracing the pain, and trusting that the software could help us solve all these new unknowns. And then we got people smiling again by working like maniacs to rapidly iterate the software to work how they needed it to.
3. Use the Big Guns on the Scary Stuff
Lastly, there is a really huge, but indirect, force at play here. By facilitating obvious needs with less effort, and building proprietary things faster, we free up our most custom and high leverage technical resources — our Product and Engineering teams — to focus on the issues that need them. Those people then make our company more Lean Startup by validating truly incredible opportunities and testing massive risks.
The Lean Startup methodology has as a premise that every startup is a grand experiment that attempts to answer a question. The question is not “Can this product be built?” Instead, the questions are “Should this product be built?” — The Lean Startup
A big part of Lean Startup is about opportunity cost. During the time our engineers weren’t building the tools we use Salesforce for, they were building things to enable the hardest and most unknown kind of customer development — the stuff that has never been done before. These are deep, proprietary, technical bets that we believe can create industry-redefining leaps in efficiency for running an office.
Those leaps include everything from optimizing our Operator (field agent) dispatching algorithm to adapting our software work in new markets and enable us to ultimately expand into new categories like Maintenance and Admin Help. All of these bets have massively transformed our business, and there are plenty more in the works.
Big bet experiments are scary unknowns that have the opportunity to 100x our company if they work. They tend to be forever ‘two quarters away’ when you instead spend resources trying to keep your house in order or building obvious stuff that you cannot learn from.
The Cabaret: Picking the Right Tool for the Job
Back to the subject of this work being ‘sexy.’ If my job description had been a copy/paste of some ’Salesforce Sysadmin’ listing from another company, Q never would have been able to hire me. I am a former founder, and have run Product and Operations in my tenure building startups. Prior to joining Q, I had just learned to code by doing a 700+ hour Web Development bootcamp. I am a full-stack founder with the experience, network, and resources to build whatever I want.
In fairness, I personally wanted to focus on scaling an operationally complex business, with a legit nuts-and bolts business model. I was sick of my previous experiences with the pixel-pushing snake oil of the adtech world, or the viral-chasing consumer app game.
As an employee, Q provides an opportunity to apply real strategy to hard problems and disrupt a huge and fragmented market for office services. We aren’t making selfie feeds or selling spammy ads into them. People pay us for the value we create, and I LOVE that. But when I joined, beyond what was appealing about the company, I knew this job would be sexy.
But this strategy isn’t about me. Making this team sexy involved planning for it to be this way. When Q hired me, they were looking with someone who would bring Product and Operations experience to our third party systems. That is why my team is called ‘Product Operations’. And in turn, when I hire, I look for three things: the product mindset, a love of learning, and technical aptitude. I do not look for people to have simply racked up years learning Salesforce’s quirks. We look for builders. We don’t see it as mere configuration. We do stakeholder interviews. We write detailed Product Requirements Documents. We iterate our approaches and use structured data to learn from what is working. We build bespoke tools that accomplish core operational needs. We take wrecking balls to dead ends and we choose to never blame our tools.
We use Salesforce to never reinvent wheels, to prototype proprietary business software faster, and to make room for our engineers to reinvent how our industry is run. We use it as a core part of our Product/Engineering toolkit for the same reason we use a litany of Python packages.
As an exercise, try asking an engineer which coding language or database is best. If they’re truly good, before answering they’ll in turn ask what you hope to accomplish. It’s always about finding the right tool for the job, and at Q, our expensive enterprise software has been an instrumental tool in huge swaths of product we use to run our business.
Update (April 2018):
We took this concept even further over my years at Q. From the beginning, the company had been envisioned as an ‘operating system for the physical space’. But despite our vision, we had been built as a completely vertical service provider serving a few key categories and markets. To realize our vision, we needed to evolve into a marketplace, and in doing so, change not only our USPs and business model, but also our product and operational model.
My team helped realize this change. We used 3rd party software to create the first versions of invoicing and of matchmaking (pairing supply and demand): two fundamentally core functions of a marketplace. Shockingly, these features ran on Salesforce for over a year as we scaled our marketplace (!), allowing our Product, Engineering and Design team to focus on the UX of the procurement experience. When our Engineers were ready to replace these features, they benefitted from a year’s worth of my team’s problem space knowledge and tweaking; and built exactly what was needed, the first time.
