03 January 2018
Article

Startup mistake #3: Not following a process — every goddamn day

This was one of the reasons we decided to shot down the startup Sentar that our 3-man team founded 18 months ago. We had the ambition to solve a big societal issue and recently got enrolled in Danish Tech Challenge 2017. So why did we decide to shut down our early stage startup shortly after? Because of a bunch of mistakes we made (we have already written about two of them: 1) being too eager to validate the need for our product and 2)letting our strategic decision-making be influenced by sunk costs. Here we would like to share our experience with the third mistake we made of not following a process every goddamn day. 

No process = Intuition = Decisions in the dark

A lot of times when we decided what to do next, it did not feel like we understood each other. It felt like the other founders spoke a different language you couldn’t understand.

Both parties were trying to “play startup”, but we didn’t agree on how to play that game.

The super annoying thing was that we were not aware of why we didn’t agree. We just argued until someone won. Maybe not because they had the best argument, but because they believed the most in their version of “the startup game”. We know this because we never agreed on how to “play startup” until we decided to shut down Sentar. So no one convinced the other party — they just managed to push their case through.

This is not the way to do it — you bet all your cards on that the strongest arguer in any given discussion is also right about what to do.

On the contrary, we believe this intuition based decision making, could have been avoided in a very simple way. And that simple way is: Following a process — every goddamn day.

But what do we mean by “process”? For us processes are frameworks, toolboxes or methods that forces you to think about every step you take and every choice you make. It is the opposite of “just doing it”.

So if you follow one or more processes in your work life, you first of all probably know what those processes are called (eg. SCRUM, LEAN, User Journey Mapping or “A Day in Life”.) Second you frequently read an article or book on these processes, and discuss them with co-workers.

If you are NOT using processes in your work life, you and your team agrees on what makes sense to do next in e.g. weekly meetings. Not based on fancy frameworks with inputs and outputs, but based on the collective common sense of your team.

The last example describes 80% of our decision making in Sentar, and today we wish that we would have followed some sort of process at least the majority of time we worked together.

So why didn’t we do this in Sentar?

Reason #1: Coming from two very different worlds

Having a diverse founding team is great. But having a diverse founding team is hard. Especially if all founders are coming straight out of school and into the startup.

Some of you might remember your last year studying and writing your thesis. We remember it like this: You have submerged yourself into countless subjects, theories and methods — become an expert and you are now ready to enlighten the rest of the world with your new and better way of doing things.
If people along your way reject your ideas, they are probably old-school or still stuck in the wrong paradigm.

Therefore it can be highly challenging to meet someone who is not “just” a part of the obsolete paradigm, but from a completely different world. In Sentar we have many examples of this. Here’s one where Christian (engineer) and Lasse (business) exchanges world views in a Google Doc commentary section (English translation below).

(English translation of the Danish correspondence above)

Engineer: I generally agree with the content, but the D&I in me (the Design & Innovation master programme Christian attended) is fighting it. I can see why we should have the customer things figured out, but if we do not have the user figured out, then there’s nothing to do. I know that it is not the user who is actually paying us, but the effect of the service becomes useless if the user doesn’t want to use it.

Business: That’s totally the chicken and the egg. Do we want to make a solution no one wants to pay for? No. Do we want to make a solution people want to pay for, but does not work? No. That’s why it is cool that we are running these 2 processes in parallel.

Engineer: OK: That’s true. It’s just that the D&I in me has learned; “it’s always the user first.” User oriented design.

This conversation took place in a document our business guy created, after failing a lot of times at convincing the other two founders, that his world view was the right one. And the document was kind of a success. Now the ideas were not directly rejected.

Now the ideas made the team talk about their core professional values; what’s most important in life? The user or the customer?

So at this point it wasn’t quite clear to us. But looking back at it, it’s obvious that we found it hard to agree on what processes to follow, we basically did not share the same world view.

For us it was the battle between User-orientated Products and Customer-focused Solutions. Who is king? Who should dictate your focus? Your Monday-Friday? Your project’s vision?

You want another example? Well we’ve got our sleeves packed with them.

This is our second prototype, which we tested with 5 employees from Tryg (a large insurance company in Denmark). 

Before going into this test we had two major questions as a Company.

1.      can we make office workers adopt this new and healthy way of working (standing more)?

2.      is that behavioural change valuable to someone?

After testing for a month we got the following results back:
– we increased the standing time with 80%
– 4/5 users were happy about the product and would recommend it to their colleagues
– the users did not understand the UI (User Interface) completely (room for improvement)
– our data was only 80% accurate (room for improvement)

As a team we interpreted these results like this: “We need to improve this technical concept significantly and test with way more users”.

What would it have looked like with a process?

If we had written the two previous assumptions in a Dashboard like this and hung it on the wall, we are sure we would have interpreted it differently.

So even if we were disagreeing on what was most important in this world, the customer or the user, a dashboard like this would have made the team realise that the second leap of faith question remained 0% answered after this test and that the first “engineering question” was not so critical anymore.

Btw these leap of faith questions are questions that are so crucial to your project that, if they are not true, you are completely screwed. So you better focus on the most critical one at all times.

Looking back at our journey we always had the shortest and best discussions when we had tested someting and retrieved meaningful data. It was like this data was the magic pill that helped us reach each other — despite our heavy cultural differences.

That’s why we wish we had followed an experiment orientated process each week.

We should have treated every disagreement as the foundation for a test, where the outcome would be a beautiful piece of data washing away our different beliefs.

But, but, but …….
Did you read our second article? Then you remember that cold November month where Mads was working his ass off building prototypes for our proof of concept, and then Lasse presented him with some pretty “negative” data from a test with our first customer group.

Did that data work like a magic pill? Not exactly. Because we were so deep into this other long process with many invested hours, dollars and sleepless nights, we could not treat this data the way it deserved. But, even so it did help the team accept that this first group of customers (large corporations with a lot of office workers) was dismissed. We just didn’t react the way we were supposed to, before we finished that other big project we were working on.

Which leads us to the second and last reason we made the mistake of not following a process — every goddamn day.

Reason #2: Being newbs (in a complex B2B industry)

When January hit Sentar and we had finalised our huge proof of concept test with more than 50 users and prototypes, we were free. Free to now focus on unfinished business from the November test: who is our customer?

And as you can see in the graph below, time spent on business did increase a bunch from January 2017.

“Great! So did you get all that beautiful data, that would help You focus on the right things and move on in an unified and awesome direction?”

No. You might think this was Lasse’s time to shine. Show off his business processes and find that target customer. But actually this was Lasse’s time to fail miserably.

Let’s set the scene. During a pitch event 6 months earlier (September’16) a guy from the insurance and pension industry told us:

“You are focusing on the wrong customer group. Corporates will never buy that from you! Insurance companies on the other hand; they feel the pain you are solving.”

At the time we just nodded our heads, because we knew nothing about that industry. But now 6 months later and we had gotten negative reactions from our first customer group, it was time to dust off that old lead.

So we researched this new industry and found out that the 5 largest and most relevant insurance companies represented 80% of the market. This seems great right? Only 5 customers to talk to, to figure out whether they had the problem we thought they had.

But we had zero phone numbers. No email adresses. Actually, back it up. We did not even know which employees within these companies we lacked emails and phone numbers to.

And if we got a hold of these customers, we had to figure out two main things.
1. How did their business work? (We knew nothing about it)
2. Did they have the need we thought they did?

Two difficult tasks that required some time with a group of these customers to obtain meaningful data. But enough complaining!We created a list of potential entrances into these 5 companies and added some of the smaller ones to increase our chances. And then started our usual cold emailing followed up by cold calls.

4 weeks of waiting and following up by phone and mails and nothing happened. By attending another pitch event, we got 1 contact with an insurance company who agreed to meet up. An old contact opened a door to another insurance company, which also agreed to meet. But that was it. We could not pave our way into more than 2 companies. The rest rejected that they needed to talk to us or just didn’t get back to us at all.

So what did the two companies say?

Company 1: We are very interested in the solution. We might want to pay for a test, so that we can push it to a customer who asked for something like this.

Company 2: There’s definitely a market for this, but only for a fraction of the price you are asking (a tenth of what we were asking to be specific). Our market is extremely price sensitive at the moment!

Not the data we were looking for. Both of them pushed us forward in a way, but none of them indicated that they, and their industry fellows, would constitute the customer group we needed.

After putting a month more into reaching out to more customers, our team decided to prioritise raising funding instead of following this process that lead nowhere.

What could have been different in this story?

Several times during Sentar’s lifetime we have talked about the dilemma of outside-in versus inside-out. Do you innovate the best if you come from the outside, fresh eyes and everything? Or do you innovate the best if you are already domain experts with a large industry network? We know this dilemma separates the innovation community.

Our take on it today is that if you do want to follow these customer orientated processes, where you have to perform small experiments frequently, you need a network. Especially if you are going into a complex B2B industry. Honestly, after the two customer interviews we managed to get, we didn’t feel like we knew our customers nearly enough. We felt like we still needed a crash course in how the industry worked, who paid who for what, where the money was made and oh yeah — finally a couple of industry conferences with afterparties so that our contact book wouldn’t be so empty.

But this is why we gave up on the processes: Because we lacked industry knowledge and industry network. And of course, because we were not clever and creative enough to obtain this knowledge and network.

That’s it for Sentar and for our 3-parts series on the mistakes we made — what now?

Now we move on with our lives. We are not starting another project together at this time. With this last reason in mind, we are going to obtain that industry knowledge and network by working for others. And perhaps some of us might never return to the startup life.

Lasse, on the left, is going to perform these startup processes for corporates working as a management consultant for Implement Consulting Group.

Mads, in the middle, is looking for new opportunties — perhaps in startups or consultancies.

Christian, on the right, is also looking for new opportunities. He is looking for anything that involves a lot of fun product development.

Do you want to contact us? We’ll keep this mail alive, [email protected], for a couple of months, so write us there. Otherwise, find us on LinkedIn.