Discover more from Data Operations
Documenting workflow is hard
"Everything Starts Out Looking Like a Toy" (No.36)
This week’s toy: an open-source tool to create flowcharts. It should be as easy to create these as it is to create documents online: by typing. Edition No. 36 of this newsletter is here - it’s March 6, 2021.
The Big Idea
When you want someone else in your company to know what you’re doing, you likely create a brief document, jot down a few notes visually in some Powerpoint slides or Google Slides, or have a meeting to discuss the project you are working on, the goals of the project, and how we all will know that things are going as expected.
Building a slide “deck”, though, is a significant abstraction from the work that goes on in most software services today. Consider that when you are talking to someone about what happens in Salesforce, it helps a lot if they know how to use the system you’re talking about or if they use it in the course of their everyday work.
When the system you are using and the work the person needs to do are divergent, how do you create a bridge between the knowledge someone needs to do their own individualized task and the broader understanding that they would need to understand everything going on in that system?
In other words, how do you explain the “work” that a person needs to do in the context of all of the “work” that is going on in that system?
Mind the Gap
“Just ask them to login”, the vendor might say when you ask how a non-user of a software platform can learn about the data in a software service. The basic assumption - that all users are capable or interested in learning a new system just to find out what’s going on in the shadow Information Technology being used in their department - might be wrong.
There are some easy reasons your teammates or colleagues might hate the idea of learning new software:
the software or their computer is too slow
they don’t have the cognitive room to learn something new
they just don’t have the time or patience
Maybe the work people have to do can be abstracted again from the system where they are doing that work. There is a new layer of productivity software being built as an overlay for Saas applications like Salesforce. Dooly is an example of software focused solely on the job to be done for salespeople in Salesforce - entering data faster - and avoids the effort of actually making them learn this complex workflow.
Custom Software Might Be Better
If you could take the interface out of Salesforce (yes, it’s been almost 6 years since Lightning was launched, and people still ask for Classic), would the jobs that salespeople need to do every day be better? For some salespeople, that would be a great answer. They have a set way of doing things and would rather the software adapted to them rather than the other way around.
In a world where interface overlays like Dooly are successful, all of the people who hate learning Salesforce would be overjoyed. But there’s a catch. When you commit to building custom software on top of another vendor’s API, there’s always the risk that vendor will deprecate or change that API. Or that they may launch a new product offering simplified UIs without the added cost of using an additional product.
Custom software is a great idea when - especially in the case of highly-compensated salespeople - you can use a tool to maximize the time they spend on high-value activities like selling and minimize the low-value cost of data entry. To make it work, however, you also need to think of the Ops teams and developers that make complicated Revenue Operations workflows work to be antifragile. Adding a layer of abstraction might be great for users, but bad for the business. When a workflow changes because of underlying business logic, we need to make sure everyone else in the business understands what changed.
What’s the takeaway? Whenever you make things “easier” for users by allowing them to have an abstraction outside of your core process instead of making the core process better and more effective, there is a corresponding cost to maintaining two systems.
A Thread from This Week
Twitter is an amazing source of long-form writing, and it’s easy to miss the threads people are talking about.
This week’s thread: on NFTs - a digital certificate to prove authenticity and value. This thread discusses the definition and doesn’t discuss the related issue of the energy used to “mint” these tokens.
If you can create a digital token, what is scarcity exactly? The argument for NFTs is that owning the one true copy is valuable. And that another “true copy” cannot be minted.
Links for Reading and Sharing
These are links that caught my eye.
2/ Put the customer first - Companies with usage-based pricing grow 38% faster than those with fixed models. Intuitively, this makes sense. If you have a product that people love, and you let them pay more when they use more, you’ll grow fast. It also assumes that you’re making a product that people love (a great north star).
3/ Measuring “talent” - How would you consider comparing “Talent” to “Results expected from that talent”? @nukemberg points out that results accrue on a power law curve, and that the most talented people might not overlap with the best results. As always, your mileage may vary ;)
On the Reading/Watching List
Is America giving up on free markets? Or said otherwise, is the American dream of competition not as American as Apple Pie? Thomas Phillipon writes about this conundrum and on the power of large firms in America.
I’m currently watching the Jodie Whitaker Doctor Who series and finding it … awesome. It manages to pay homage to classic Who while seeming new and fresh. Worth a watch!
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
I’m grateful you read this far. Thank you. If you found this useful, consider sharing it with a friend.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon