Friday, April 23, 2021

Data Value and Volume are Inversely Proportional

In 2006, Clive Humby coined the phrase “Data is the new oil”. This is often misinterpreted as “Data powers the economy”, particularly by folks who sell data processing and storage, but it’s useful to see what someone who actually uses data says. In 2013 Michael Palmer, of the Association of National Advertisers, expanded on Humby’s quote: “Data is just like crude. It’s valuable, but if unrefined it cannot really be used. It has to be changed into gas, plastic, chemicals, etc to create a valuable entity that drives profitable activity; so must data be broken down, analysed for it to have value." 

Much like refined oil (or processed ore for that matter), the volume of material is reduced as the value is increased. This concept should be intuitive to anyone who’s ever manually sifted a pile of data into a thin report, but it’s sometimes lost in contexts where locating a needle in the haystack is the analyst’s goal. Adding human effort reduces volume.

Corollary: if the project requires massive amounts of data storage, it might be worth asking how much value is going to be in there? Is the purpose to store as cheaply as possible and rarely retrieve? Or maybe the plan is to figure out value later

There’s an interesting confluence of partially aligned incentives between people who have to retain large amounts of data, people who want to retain and access large amounts of data for analytics, and people who just want answers to problems today. “Storage and compute are practically free”, which is why Amazon Web Services is worth 1.5 trillion USD in 2021. If you don't have to pay the bills, collecting raw data for real time analytics sounds great. Otherwise, you'll need to consider this project's needs for data modeling.

A Simplistic View of Venture Capital

I have a lot of conversations with people. 1:1’s, interviews, &c. When the opportunity arises, sometimes those who’ve done startups will talk about their experiences.

There’s sometimes a flag in those conversations about startups that raises my hackles. It’s a description of the money raised as if that were a success metric. “I was at blah”, or “I founded a thing called foo”, and “we raised dollars!” 

I think it’s from accepting the Venture Capital narrative as presented on Shark Tank: that businesses are competing for the pool of dollars, and that the VC’s are judges of innovation. I also think that is a false and self-serving narrative. 

Venture capitalists are salespeople. They are selling a financial product, basically a fancy mortgage. You give away future equity in your house or company for upfront cash today. Good on you, salespeople who can make buying your product seem like a competitive win. 

It is true that have to do your homework in order to get VC investment, and it's more work than a mortgage: a business plan that discusses how you are going to financially swing your journey to product market fit. You also can’t get a mortgage if you don’t fill in a bunch of paperwork with indications on how you’ll pay it back.

The problem with this analogy is that you don’t have to convince a bank that your idea for buying a house is both excitingly novel and fairly safe, you just have to fit the expected cultural and financial parameters. On second thought, given the history of redlining, the analogy between mortgages and venture capital seems pretty solid.

Evidence of purchasing a product is not a symbol of success or status, it is a symbol of in-group membership plus basic competence. 

Back to the interview context, use of this trope is a yellow flag that the candidate may have trouble recognizing or accepting that a thing hasn’t worked. If they can’t point at anything more positive than raising money, their business failed. So they’re spinning a story at me, nothing wrong with that. But I need to see an indication that they can launch a product, so I’m going to keep asking questions.

Update with this excellent thread 

Product Tempo versus Deal Tempo

Going from sales engineering to product management  was a jarring transition at first, because it represented a change in tempo. As a sales engineer, I lived by the fiscal quarter. While a given customer might be a multi-quarter job to convert, my sales partners and I had money to make and were judged on a quarterly basis. Our bread and butter was the quarterly cycle of identifying opportunities and closing them. I wrote software to help my customers and learned some lessons that way, but the jump to product management in enterprise development organizations still surprised me.  

Shock number one: resourcing. From the field, you can see numbers like the allocation of headcount to engineering, and you can easily imagine that there are dozens of people working on a product. From the factory, you’re more aware that a team of dozens is rare, and a given product probably has one to six actual humans working on it — if you’re lucky. A platform company can do an amazing amount of value creation with small teams, but they can't do everything.

Shock number two: here comes the flood. All products have an incoming stream of tickets. Customers and partners have support requests, bug reports, and feature enhancement asks. Maybe it’s a small trickle, but if the product is successful, there’s at least dozens a day, maybe hundreds. You can try to offload it on someone else, but rigorous process is the only effective answer in my opinion. As a field engineer it can seem that a good idea is its own justification. As a PM, that good idea is only a starting point.

Shock number three: tempo. As the title of this post indicates, product time scales are very different from sales time scales. As a field engineer making free software development feels fast. You write some stuff, it works in your lab, you post it for some friendly users, iteration chugs along as fast as you can go. As an R&D scrum team the process is much slower. You have more platforms to support. You can't rely on some software licenses. You have to think about adversarial use cases and product security. You have to coordinate your activity with the rest of your team in order to build sustainable and supportable software. Bug fixes can go pretty quick, but as a rule of thumb, adding a meaningful feature takes a quarter. Adding a minor feature takes at least a month.

Here’s some advice for sales engineers and similar field characters — of course you’ve probably heard it before, summarized as “Sell what’s on the truck.”

  • If you’re expecting a product change to save your deal you’re making an account management mistake. “Sell the sizzle not the steak” is about making your product look good, not about building a deal on dreams.
  • Shipping product is for dinner, roadmaps are for dessert. The roadmap’s function is to demonstrate that the company is still investing in this product, not to establish a schedule of future feature deliveries.
  • Those said, there is a counterpoint: If you don’t sell it, it will never be fixed. Selling the products is essential to the success of a software company, and if customers don’t use the products then they won’t sell very well. Without sales there’s no one validating features work, no one finding problems, and no reason to fix what’s already known to be suboptimal. So you’ve got to have faith that what the factory says will work can be made to work. 

Followed by advice for product managers coming from the field, which you may have heard as Eisenhower’s quote: "In preparing for battle I have always found that plans are useless, but planning is indispensable."

  • Your tempo has changed, not your activity. Where you were preparing a customer to buy or renew a product (quarterly tempo), you are now preparing the company to invest or maintain investment in that product (yearly tempo).
  • Your scale has changed, not your motivation. Where you were helping a customer to use the product successfully, you’re now helping all customers. Where you were helping a friend with their deal, you’re now enabling the entire field to position your product correctly. Where you were convincing a product leader to prioritize a bug fix, you’re now convincing an engineering leader to allocate person hours.
  • The future is an unknown country. There are only three time buckets that matter. The present has what you’ve recently shipped and the things that engineers are working on now. There is a good chance it will work. There is what you want to do next, which you’re currently designing with your engineering counterparts. There’s a 50/50 chance this will eventually ship. Everything else is in the backlog and does not matter. You can draw a pretty picture of a roadmap with releases for that stuff, but it’s fiction. Its purpose is to build excitement and set up resourcing for next year.

Summarizing, watch out for this offset in tempos, because it can cause inaccurate expectations.

  • It takes a quarter for enterprise software product changes to affect sales numbers, because smart field people won’t sell it until it exists. 
  • It takes a quarter to deliver a change to an existing product because teams of engineers have to build sustainably. So if you have to make product changes with existing engineer allocations to affect this year’s numbers and you’re just planning them at the end of Q1,  you’re going to deliver them in Q3 and you’ve got all your eggs in Q4. 
  • Whatever plan you offer for making new product without allocated engineers is setting up for next year’s sales at best, assuming you convince leadership to rob an existing product or hire new engineers starting now.
  • SaaS doesn’t change those dynamics as much as people might assume that it does, but it does help to smooth out a spiky cash flow.
  • Acquiring a company instead of building software provides a faster bump to your sales numbers because you can just claim the new company’s numbers as part of your own; but it also hurts your ability to deliver software later on.