Capturing learnings

One of the things I am trying to do while we work to get our new MedTech startup off the ground is to document my learnings so far.

I do that in a mindmap using SimpleMind. Because when taking notes and reflecting on things the easy of speed of getting it down into some sort of structure beats trying to get the format right from the go.

Anyways, the learnings I am documenting serve a couple of purposes;

First of all, I am trying to get the learning myself. Reflect on the things we have done as a team and I have done as an individual and try to use the instances, where we could have done better or been more efficient, to become better and more efficient in the future.

Second, I am trying to document whether there are some patterns in what we have done that we can put on formula for later use and thus make the next startup startup process a bit more smooth.

Looking at the latter point, two things have already become abundantly clear:

There are a lot of learnings around process; when to do what in order to create a flow where everything around establishing the team, the corporate structure, strategy etc can happen at a pace, where people are in it and don’t risk feeling either overwhelmed, not heard or just straight out of the picture. I think those learnings are universal and can be directly applied to other future cases.

On top of that there are a lot of learnings about people; what’s important, what’s not important, how to interact in ways that builds a great degree of trust, which I think is absolutely key for a future long term corporation to work. Some of those learnings are directly applicable to future cases, but as it relates to people, and people are inherently different, some of them will have to have major adjustments on a case by case basis.

Basically, two things are fascinating for me in jotting down those learnings:

The sheer volume of notes, thoughts and reflections is just daunting and is both a reminder of the process so far and the sheer amount of work, we have put into making our new startup work for everybody. But it also has immense value in itself as a future (part) blueprint for how to do these things.

The other thing is that I will be curious to see what will end up being the differentiator for future cases and the applicability of our learnings to them? Will it be predominantly the process parts of the people parts.

The jury is still very much out on that one and as such the journaling continues.

(Photo: Pixabay.com)

Talk code as non-coder

For quite a while I have been deeply fascinated with no-code platform Bubble. It’s immensely powerful in itself, and it allows no-coders like me the opportunity to dabble a bit into it and try to get an understanding for how code structure actually works.

But it also presents another huge advantage: An improved ability to understand and communicate with coders.

Here’s how I am trying to do it:

The Bubble editor contains a number of separate workstreams. Two of these are Data and Workflow.

Start with Data. Here you can define the properties that should go into your database, ie the different datapoints you would like to capture, store and manipulate as either part of a function of your service or the user itself.

You can essentially map out your business model here. Think about what you need to capture, and what you need to be able to do with it. And make sure that your database is structured based on it using telling labels etc.

When you have your database table in order, you move onto Workflow.

Here you can pick out individual labels from the database and basically do a IF THIS THEN THAT analysis on them and just map them out one by one. You can do this through fx a mindmap where you specify that when you’re looking at this function or feature, and a specific thing happens, the result should be something like this. And then repeat the process, until you have all aspects mapped out.

Using this approach you will end up with a serious of pretty well-structured maps that will illustrate your core functions and how they should operate and spelled out in a way that should make it easier for you to have the conversation with the coder(s) who are going to build something.

Because even if you can’t completely speak their language, you have at least made a real effort to try to bridge the gap – and all things considered you will be a lot closer to a fruitful dialogue.

(Photo: Pixabay.com)