< all Blog posts

Doctors want software engineers to spend more time in hospitals; do we spend enough time in dispensaries?

https://www.pexels.com/photo/three-person-looking-at-x-ray-result-1170979/

I’m a frequent visitor to the YCombinator forum “Hacker News” and a recent discussion there struck me as very relevant to cannatech and any teams that build business software. The CNBC article, titled “Doctors are asking Silicon Valley engineers to spend more time in the hospital before building apps” focuses on the work of Dr. Richard Zane to bring healthtech companies and medical professionals closer together. Dr. Zane is an emergency room physician and the CIO of UCHealth in Colorado; he explains that “tech companies more often than not have a preconceived notion of how health care works” and often have “gone very far down the path of building a product” without enough first-hand perspective. He’s aiming to fix that by inviting software companies into hospitals so they can build tools that fit more seamlessly into a doctor’s workflow.

Dr. Zane’s conundrum rings very true for any B2B software team – how do you make sure that your tools make life easier for your users? How do you make sure you’re solving the right problems, and making the right improvements? When you’re building a consumer product your average users all around you; but when you’re building a business tool, you have to make a determined effort to understand workflows that you don’t see every day.

Is your cannatech company cannabis-first or tech-first?

My interview on the Vangst Seed-to-Sound podcast got a lot of response to one particular point: that some cannatech companies are cannabis-first, and some are tech-first. Cannabis-first companies might be new to building technology but they know a lot about how cannabis is produced and sold, and know what tools would make that process easier. Tech-first teams are often new to cannabis and while they bring strong tech chops, they can struggle to understand the processes, workflows and culture of the industry. Cannabis is absolutely an industry with a lot of “pre-conceived notions of how it works”, to borrow Dr. Zane’s phrase. Even if your team is filled with former cannabis operators, the industry changes fast and there’s no substitute for seeing your customers’ workflows first-hand. Do cannatech engineers get out enough, or are we as lost as our healthtech peers?

A case study: how regulatory restrictions impact cannabis workflows

Regulatory rule-following is a major part of cannabis operators’ day-to-day workflows, but it’s very easy for a software team to overlook the impact of these regulations if they don’t slow down and ask the right questions. One of my favorite stories to illustrate this comes from a conversation I once had with the General Manager of a very large dispensary as he explained how he receives product deliveries from vendors. He explained that receiving shipments was a major disruption for his business – he had to schedule extra dedicated staff members, set aside time and schedule the deliveries carefully to space them out over several days. It was one of his biggest headaches!

I realized that I had to understand this problem further if I was going to try to solve it, so our conversation went a bit like this:

Me: Ok so I understand deliveries are a major disruption, but why is it so bad? Why isn’t this problem solved?
Dispo GM: Well we’re just such a large dispensary, we’re the biggest in our whole state! Our shipments are huge and we have to receive new product every week just to keep our shelves full.
Me: But I’ve never heard of this problem before, and receiving product is hardly a new idea! Why so much trouble?
GM: Other dispensaries shipments are significantly smaller, they can count the products in maybe 20-30 minutes but it takes us literally hours.
Me: Hmmm but what about like, 7-Eleven? Surely they take massive shipments every day, they must have figured this problem out somehow?
GM: Ah but they don’t have Metrc.
Me: I’m not sure I understand, why does that make such a difference?
GM: Well here’s how it works outside cannabis – you get a shipment of Snickers, maybe several boxes containing 500 candy bars. The vendor leaves, you put the boxes in the back. Over the next two weeks you stock your shelves, you sell the candy bars, and you keep count as you go. At the end of the two weeks you might realize the shipment was 50 candy bars short – so you call up the vendor and there’s a certain amount of trust in a business relationship so they probably just apologize and promise to send an extra 50 in the next shipment. And you just move on.
Me:
Sure, that makes sense. Ohh… wait I think I’m seeing the problem.
GM: Right, you can’t do that in cannabis. Because if you discover you’re 50 products short at the end of those two weeks-
Me: Metrc is off..
GM: -your inventory count has been out of compliance for two weeks at that point! Your vendor’s inventory count has been out of compliance. Your transfer manifestos are wrong. Your delivery was not compliant.
Me: And that’s a huge problem.
GM: That’s a huge problem. So we have to count products as they arrive, ideally before accepting the transfer but at least day-of, so that we can update Metrc if the count is off. Other retail operations don’t have to worry about that immediacy. Hence the massive headache, huge time-suck and extra labor costs, etc. Because of Metrc.
Me: Because of Metrc and because of regulatory compliance.

In this conversation I almost missed understanding a major problem because at first the GM explained the issue as merely a function of the dispensary size. As soon as I understood the problem, I could see potential solutions – delivery boxes designed to guarantee the count? Stickers on each individual product, and a mobile app that scans/counts the stickers? Surely you might have your own ideas.

The regulatory rules are so second-nature to operators that they don’t even see them anymore – they just accept the restrictions as a fact of life. As software teams we have to listen closely and push them to explain the boxes that they live in every day. Only by digging deeper and asking why his workflows went a certain way, was I able to find the important issue at the center of the problem.

What other kinds of things can we learn about our users’ cannabusiness workflows?

Why do they use paper and pencil instead of a computer?

As technology professionals we’re quick to assume that every workflow is better when it’s moved onto a computer – but a lot of cannabusinesses don’t agree. You’ll want to ask your customers why, and ask yourself how your software can compete with the simple reliability of a notepad or whiteboard. If you’re wondering why their warehouse shelves are covered with paper labels, don’t forget that Metrc tags themselves are on paper, and legally required to stay with the package! If you’re wondering why grow room data lives on a whiteboard instead of a cheap tablet that could hang in the same spot, ask yourself if that would really reduce be easier or if it would just be flashy and futuristic.

You know retail, but do you know farming and manufacturing?

Many cannatech companies focus on retail operations, and the reason is obvious: we all have a pretty decent understanding of retail. We go into stores every day, we even walk into dispensaries pretty often. But a unique aspect of our industry is how many of our clients work in farming and manufacturing! Do we understand how those work? How many of us had ever been onto a factory floor before we started working in cannabis? Improving factory workflows used to be a whole industry (the real-life Cheap by the Dozen family were pioneers!) but now most Americans don’t even know anyone who has worked in one. As cannabis operators build modern candy factories and chemical extraction labs and indoor farms, they’re looking for the best technology tools and we have a lot to learn!

Can small UX tweaks save them hours?

In the Hacket News discussion, one particular comment jumped out at me about an engineer’s experience with their users:

“I actually did get to spend about two hours with some actual users of my software a month ago and I noticed that they were scrolling up and down a lot. I asked if it would make their workflow quicker if I made the save button float in the lower-right corner of the browser (I.e. position: fixed). They said, ‘you can do that? Oh my God, that would be amazing!’ It took two seconds of CSS and has saved them hours already.”

Every piece of software has the potential for major improvements with minor UX tweaks – what are yours? Do your Sales users need your tool to work on the go? Do your Grower users often have wet hands? Does the packaging team painstakingly type Metrc IDs when you could implement a scanner with a day’s work? Your users will love you for finding the answers.

The good news: we still have it easier than our healthtech peers

After reading the CNBC article and the HN discussion from healthtech veterans, I had to compare it with my experiences in cannabis and feel grateful to be in our industry. For all the complications of building in cannatech, we have plenty of advantages too:

  • we don’t have to deal with massive software conglomerates like Epic Systems that run every bit of a hospital’s operations and leave very little room for startups to innovate
  • while all B2B software companies have to deal with the disconnect between software buyers and end-users, it’s much smaller at a 20-person cannabis company than at a 300-person healthcare facility.
  • if you need an expert, there are smart and experienced operators all over our industry – and hiring a former dispensary manager or master grower is certainly more affordable than hiring a surgeon.
  • between HIPAA and the large healthcare bureaucracies, visiting a cannabis facility is significantly easier than seeing a hospital’s operations first-hand.

What are your thoughts?

What are you doing to see your clients’ cannabis workflows in progress? Are you making enough visits? Are you asking the right questions? If you’re a tech-first company, are you bringing in enough cannabis-first perspective? The success of your technology product might depend on it.