Functionality vs. fascination: what do you value in your software?
Functionality vs. fascination: what do you value in your software?
The biggest challenge in b2b software is user activation. Do you want your users to do a few things well, or to be able to do anything? Read: "Everything Starts Out Looking Like a Toy" #152
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? is a post that grew into Data & Ops, a team to help you with product, data, and operations.
This week’s toy: a shopping feature to show you clothing items worn by different example models. “See how I look in this” is undoubtedly next, and it’s strange to think about how this will work virtually. Now, if they could make it easier to return items that don’t fit if even if the AR view suggests they will… Edition 152 of this newsletter is here. It’s July 3, 2023.
Brought to you by Pocus, a Revenue Data Platform built for go-to-market teams to analyze, visualize, and action data about their prospects and customers without needing engineers. Pocus helps companies like Miro, Webflow, Loom, and Superhuman save 10+ hours/week digging through data to surface millions in new revenue opportunities.
If you're reading and haven't subscribed (yet), give it a try! And if you have any comments or are interested in sponsoring, hit reply.
The Big Idea
A short long-form essay about data things
⚙️ When you open software, do you know what to do?
In 2010, the Fisher-Price iXL learning system promised the following capabilities for 3 to 7 year old kids using a single device: “a child's Digital Book Reader, Game Player, Digital Art Book, MP3 Music Player, Notepad and Photo Viewer.”
This toy looks primitive to these same people in 2023. It came along before iPads, dedicated educational software, and more sophisticated toys for kids and adults alike. Yet it offered a lot of specific capabilities to users.
Compare that view to this set of educational instructions to build a “Rube Goldberg” machine, a scientific project for high school physics students to teach them the principles of exploration and the scientific method.
Succeed in this experiment, and you have the tools to solve almost any engineering problem (within reasonable constraints, of course).
Take a closer look at these two options and you have an interesting mirror of the software business.
The first option appears too simple to be useful: a few buttons, a click wheel, a volume control, and a stylus. But it drastically limits the path that users can take to find value, and the permutations necessary to support the different things that might happen.
The second promises a “choose your own adventure” kit that can do … well, anything. You can solve any problem. And troubleshooting that problem might require a pretty sophisticated breadth and depth of knowledge.
When you’re building software, should you aim for “so simple, even a toddler can use it” or “it can do anything”?
Start by considering the user experience. In the perfect scenario, you build something that teams love, use all the time, and adapt to serve changing needs. The more typical result is that they use it when they have to use it, and not more often.
Your high performers are going to do fine in any situation. What about the rest of the team?
Do you want users to do and repeat one simple thing, or build a process that works for them?
Think about how many work-related apps you use in a day. I’d guess that most people use relatively few applications most of the time (Google Workplace, Slack, and a CRM being high on the list). Yet look at the graphic above showing the average number of apps used in an organization: over 100.
That means that most people will not log into an app very often. When they do, it needs to be pretty easy to do what you need to do.
To get better adoption, you need to make features as simple as possible, and not simpler.
Applying simplicity to RevOps: don’t build it all
What does this mean for revenue operations professionals? It means that you have to choose your enabling applications and workflows carefully to get the best performance from your teams.
In a lot of ways, this is a classic build vs. buy decision, but with a twist. Normally when you think of “build vs buy” it’s about the decision to build your own software or to buy other software instead.
In the era of composable applications and CRMs that can do anything like a Rube Goldberg machine, your “build” decision might entail building complicated applications on top of an existing platform. It all starts with a simple request, and building every request without a RevOps roadmap can result in a lot of (no-code) software and process debt.
As a RevOps leader, you need reps to follow policies and to run playbooks consistent with your procedures.
When a sales development representative is looking at their complement of 1000 accounts and trying to determine which 20 prospects to approach today, do you want them to build their own process?
You want them to know what to do and to go do it. This leaves team members time to speak to prospects and doesn’t make them wait while you build a Rube Goldberg machine.
When you buy a solution that does exactly what these reps need, you don’t want them to have only three buttons to push.
How do you balance these competing forces?
Creating a playbook to match your environment
In the real world, you rarely have software or work processes as simple as a Fisher-Price toy or as complicated as a Rube Goldberg machine.
You do control the playbook you want to run. If the goal is to make sure that sales development representatives have a ranked list of 50 people to contact in a workday, that’s the basic feature.
Said another way, evaluate the build vs. buy decision by:
Deciding what you need the team to do and write it down as a sequential outline or procedure
Writing out a use case as you would a feature, e.g. “As a seller, I need to have a ranked list of the top N accounts I need to contact today, and a way to respond to them instantly within the same application. After I respond to them I need them to move to a different list where I can keep track of the responses”
Identifying entry conditions for entering the workflow, e.g. the scoring algorithm that you need to use to rank accounts, the delivery graph for new leads to distribute them to various people, and the expected information you need to be able to run a selling playbook
Define how you want to track success or failure of the playbook in a simple report
Once you have the blueprint available, it’s a lot easier to evaluate whether you want to buy a solution or build a perfect Rube Goldberg machine. (P.s. don’t forget time and cost when thinking about this conundrum.)
What’s the takeaway? “Build vs. buy” is still something you need to consider when you are building customizations on top of an existing commercial platform. Make this decision easier for yourself by treating your RevOps workflow like a feature and drive the process like a product manager.
Links for Reading and Sharing
These are links that caught my 👀
1/ How far can you drive a typical EV? - Whenever I consider buying an electric car, I wonder how the EPA ratings for mileage compare to real-world experience. Thanks to Recurrent, you can now compare drive ranges among the same brand for Tesla, Ford, Volkswagen, and others.
2/ Graph examples in React - Yan Holtz is curating a wonderful library of React/D3 graphs. The next time you need to demonstrate to an engineer how to build a graph for a feature, look here for sample code. (You don’t need to know how the code works; but it helps to have examples when engineers ask: “how is that built?”)
3/ The different kinds of freemium - The PeerSignal team put together an informative summary of different kinds of free trials. We used to call this a “free trial” with little difference, and now there are several different models to convert top-of-funnel traffic to subscription.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
Want to book a discovery call to talk about how we can work together?
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon