5-step process for starting a cannabis tech project

The perspective of a new project is exciting and emporing, but statistically most software projects fail (~75%) and at this early stage, one's main goal should be to reduce the inherent risk of launching a new technology initiative and learn as much as possible before building. Regardless if your target users are your internal team or a broader audience, we believe the steps for doing so are foundamentally identical.

Pinpoint the main pain

Focus your efforts on solving one specific pain. This will allow you move fast, quickly validate your hypothesis and help you align team and stakeholders on the same page. Big and complex solutions become a success only when build incrementally, inside-out and not the other way around.

Analize existing solutions

With a clear pain point, it's important to analize all existing solutions (in a new industry like cannabis there could be none). This will save you from building something that already exists, but also give a good idea of the competition. We recomment doing a SWOT analysis.

• Crunchabse - Cannabis companies

Jot a roadmap

HONE offers professional strategy and design sprint iterations to put you on the right path.

Needless to say it, cannabis is a heavily regulated industry and you must carefully navigate around the jurisdicial regulatory framework in regards to any technology plans. Failing to do so may not only jeopardize your initiative but also have serious legal consequences.

Consider the existing frameworks in place and also what choices the policymakers are considering both locally and abroad to increase the odds for building a future-prood solution.

Along with ensuring cannabis compliance, consider that depending on the domain (manufacturing, clients, logistics, etc) your solution could be falling under additional regulatory frameworks like GDPR, HIPPA and others.

Resources

We cannot make legal and compliance recommendations, but for informative purposes, the following could be helpful:

• Wikipedia - Legality of cannabis
• Creational Europe
• CMS - Legal cannabis guide
• Cannabis policy

With a clear problem to address, a roadmap projection and a regulatory assessment, you can move to scoping and building your MVP.

Determine scope

The purpose of an MVP is not to represent a final solution but to offer a taste of the main concept and serve as a prototype for testing with real users. An MVP should be minimalistic enough so that it does not require a significant financial/time investment but yet offer a sufficient amount of the core functionality. That requires saying no to all the nice-to-haves and focusing on the core concept. As a general rule, building an MVP should take a few months and definitely not years - faster is better.

Define success

Set measurable performance indicators to give you feedback on whether to push forward pass the MVP stage of the development or not. We like creating a list of hypothesis that we validate during the next stage.

Technology

Pick a tech stack that allows you to move fast and yet offers room for short-term scalability. This will allow to keep any initial tracktion by building on top of your MVP and not have to jump into reworking the whole thing right away. Leverage open source technologies and all relevant third-party APIs that can save you time.

HONE offers professional software development services for cannabis-related projects.

The moment your MVP is ready it's time to roll it to some real users and gather feedback. That's easy if your project is for internal company use, but if not, by that time you should've hustled your way to having some early adopters, eager to try it out.

Ideally, your early adopters would match the following:

• experience the problem you are trying to solve;
• have awareness of the problem;
• have been or are currently seeking a solution.

Create a strategy for attracting and motivating early adopters according to the specific domain of your solution.

Once you have the early users on your app/system, it's time to collect feedback and validate your hypotheses - this is the reward for all the work done so far. There are a few ways to collect feedback from the users:

• conduct individual user interviews;
• track their behaviour within the solution;
• do surveys.

Gather the user data and use it to create a matrix with the hypotheses you've defined. Here's an oversimplified example:

Hypotheses	Metric	Result
Takes users X amount of time to do ABC.	Minutes per task	Y minutes on average
Users would not prefer to do ABC the old way.	True / False	True
Users would more regularly do ABC because it's faster/easier.	True / False	True

This hypothesize-launch-learn cycle will provide you with sufficient enough data whether to proceed and a solid ground for doing so if it's the case. The result of the cycle would fall in either of these three categories:

• positive feedback - you proceed to invest in the project and expanding the prototype;
• negative feedback - you scrap the idea and not waste more time and money on it;
• somewhere in between - depending on the details, you make a call whether to do adjustments and reiterate with the users or scrap it all.

This framework can save you from making the most common and expensive mistake when starting a new tech project - building something no one actually needs. You can use it to launch entire new projects or new features within an exsting project. If you follow each step, you'll be able to identify early major issues before you make a significant investment and increase the chance of success.