Boy, was I refreshingly naive! Not yet naive enough to actually start something just like that, but get informed and involved before. Yet, it was perfect to dig the whole start-up topic. Later, see a starter-pack of my personal recommendations to this topic. But first, let’s get to business…

What’s the situation?

Soon, he will finish his dissertation in medical engineering. A really smart, friendly and quick-witted guy. A friend of his asked him what he wants to do after he’s done with the diss. After they talked, he ended up with an offer. He can get involved in the startup his friend founded. He’d get paid way under his market value, but owns company shares. Wow! What a tricky situation. Tough call, I’d say. This led to him asking me how much such a startup can be worth, unfortunately without any further context.

Obviously, there is no clear number I could tell him, no yes-or-no, do-or-don’ts. Instead, I tried to convert my current state of mind into a dense checklist. He could use my thoughts for checking if it could be a proper invest.

My advice

I tried to roughly differentiate between four main criteria-categories. All can be crucial for taking this decision:

1. The Problem
2. Strategy and Methodology
3. Figures
4. You

Just remember: The answers and gotta fit to your liking. There’s no “good vs. bad”. In most of the cases, there is no right or wrong – it is entirely up to your thoughts, preferences and personal plans.

Point 1 – The Problem

Meaning the problem the startup should be called to solve.

• Do you yourself believe that enough people have this problem AND want to solve it AND don’t want to solve it well enough in another way?
• How much work has been invested into the startup already?
• Is the founder already too much in love with his solution? This is like a pre-programmed deathblow for a startup. Founder and their team should be in love with the problem instead!
• Can a solution to the problem be sold/presented well and possibly monetized in the long run?

Point 2 – Strategy and Methodology

• Does the founder want to achieve a good exit, that is, sell the solution at a great value to a big fish?
• Are there plans to scale the company asap, or put in a HEALTHY growth?
• Is the Founder (or someone else in the team) a good salesman/ speaker? Because this is one of the most important activities of a founder: selling!
• How methodically does the startup proceed? It is important that the management team is really literate and enthusiastic about lean startup/ design thinking/ design sprint/ human-centered design! Like this, a startup increases the probability to alleviate the main problem of startups in the best possible way: too little time for much too much to do. Read about my info starter-pack recommendations below.

Point 3 – Figures

To come back to his exact question. Of course, there are these and such cases.

• How is the financial plan and current situation?
• It is quite possible that in the first 3 – 7 years business will not be in profit. Still, it can increase in value if it proves itself to be growing strongly (not necessarily by headcount).
• In Germany, startups with a hardware product are usually much more likely to go into prepayment. This is followed by lower margin promises and scalability, as opposed to digital goods.
• German investors are not very fond of high investments (in comparison to other countries). That’s (also) why digital products (and especially platforms) are more of a trend. As a team of five you can already solve a huge problem at scale. Not necessarily the first solution has to be scalable, though. A pearl of start-up wisdom says: Do unscalable experiments first. Find out what you need to do without too much pre-investing.

Point 4 – You

• Is the vision suitable for you? Can you feel being a missionary for what the company wants to stand for? Does it catch you, and you feel the fire burning inside of you?
• Are you ready to join the company full-time? Maybe you don’t need to invest much more than 40/ 50 hours per week to be successful. Still, usually, the bottom line is that it’s more like two full-time jobs. Especially if you have shares in such a company. Your motivation might be pretty strong to get it profitable.
• Statistically, your chances are about 10% that you can make a profit with your shares. By the points above you can decide whether it is rather less or rather more than a 10% chance.
• Determine the possible effect on your CV. E.g. in my friends’ case working in a startup is actually doing good to his vitae. As a postgraduate, he’d prove his interest in the market and the creation of good products, as opposed to being brain-bound (as postgraduates are said to be).
• So your main investment would be your work performance and the opportunity costs (salary you could otherwise get).

Info Starter-Pack

Here is my personal list for getting informed. Listen to podcasts like Masters of Scale by Reid Hoffman and Wireframe from Gimlet Creative. Check out TEDxTalks, and start with the one that’s really sticking in my head Start With The Why by Simon Sinek. Figuratively eat books like Lean Startup by Eric Ries, Inspired by Marty Cagan, User Story Mapping by Jeff Patton, Sprint by Jake Knapp, John Zeratsky and Braden Kowitz, Actionable Gamification by Yu-Kai Chou, Even Ninja Monkeys Like To Play by Marczewski, Hit Refresh by Satya Nadella and the Autobiography of Goetz Werner. Don’t just read them, but work them through! Make notes, summarize chapters and make notes for your later self (even if you might never read them again). Go on Founding-enthusiasts-meetups, participate at Hackathons (like us), talk about your ideas and concepts and explore the unexplored.

Now, around 1.5 years after I started digging the topic, I ended up becoming a product owner in a solid startup called sofatutor, and this brought me to a realization. If you wanna make the world a better place, solve real problems of the people and create something special, you don’t necessarily have to be a founder of a startup yourself. Every (small) company can win by people like you. You can bring all your enthusiasm into place and make it to your project!

So what do you think? What would you tell him? What’re your favorite reads about Startups and how to create a product your customers love? Let me know in the comments below, write me a message, link this post in your own blog. I’m very eager to hear other and additive opinions.

Keep up the challenge!

Yours

Sören

She is a strong personality, an overachiever, a hero, a secret leader – even if not all of the above apply to your teammate, she still can be one. In this blog post, I will try to make you understand, why those (hereafter called) overachievers carry a huge risk for an agile team (and company) inside. It is easy to ignore, tolerate or just accept, but if you and no one does anything about a team-substance like this, it can react poisonous when combined with wrong elements. Dare to let it be as is, and you will suffer the consequences, just like the rest of your team. The way of least resistance is not always a good choice.

But what is so bad about it?

Depending on the overachiever and the team, the following things are possible to happen to some extent:

• Skill development, success, and outcome should be team achievements. If only one person gets all the credit or is the go-to-person for everything, the rest of the team starts feeling discouraged. Why try harder, when you can only do your job, hide behind her and work off the 9to5-duties? Falling into this behavior, makes your work ultimately seem meaningless. Friendly colleagues, a more or less appropriate salary or a nice environment will not motivate on a long run. If you lose the mission, why stand up in the early Monday mornings at all?
• You wonder how she does it? She might never let you know. Overachievers tend to take over the tasks, with the mentality of “If you don’t do it yourself, it won’t be done (properly)”. Like this, she thinks (or says): “By the time she explains it to you or someone else, she has it done by herself”. The latest, when you hear one of those two phrases, your alarm should go off! She eagerly maintains her knowledge island and makes it grow. So the team success depends on her, sometimes only on her. This puts the team and the organization into a bad place when she feels like she wants “more”, is on vacation, simply not there, or even leaves. In Agile Teams, this is worst case in action! Because…
• It is easy and seems intuitive to mismanage: teams and even companies die in the long run due to encouraging overachiever to save the day over and over again. This is what I saw going down at Goodgame Studios back in the days: They get the feeling that they must be held within the team, or it will fail. Bad/ inexperienced managers tend to think they need to give everything to keep them in the company. Suddenly, that overachiever finds herself as people-manager, not able to perform like in her original profession. As a result, the company traded a highly professional developer (or whatsoever) for a “bad”-leader. That’s a lose-lose-resolution. For a manager, it is easy to overlook the short-sightedness of the success of such an overachiever. Therefore, it is important that everyone understands: A mismanagement of such overachievers is a threat to sustainable success.
• Overachiever have their specific characteristics. Your teams’ approaches and results will lose it’s exploratory diversity when she is always “in the lead”. Remember: the Product Owner brings the “why”, the Scrum Master the “how” and the team the “what” (see https://www.boost.co.nz/blog/2018/04/successful-scrum-team-product-owner).  By having the same approaches and doing the same type of work, you will lose the important ability of scrum teams: solving unknown and complex problems. Work starts to feel highly repetitive and – again – meaningless. The rest of the team starts mirroring her, by also over-/underthinking stories or spending too much/not enough time on general discussions. Moreover, the personal development of each team member will suffer, when no one breaks this pattern.
• Team member feel like they cannot contribute, so they start letting the overachiever make all the talk-work. This ultimately leads to letting her also do all the thought-work (because it’s convenient)… And even though it’s an overachiever in the lead, she might not be aware of the specifics of her “power” and influence. The team ends up with getting poorly directed. “People [working for an overachiever often] do not understand where they are going. They’re just following the walk of this turbocharged leader, who doesn’t direct the team but focuses on output. They get annoyed, exhausted, and feel that they need to second-guess what the leader wants because they’re not being told.”, Goleman, D. “Leadership That Gets Results,” Harvard Business Review, March-April 2000.

What to do?

The main objectives are:

• Let the overachiever share his knowledge (to reduce knowledge island risk),
• Give every person equal opportunities to provide their input (to live collaboration and achieve diverse approaches to master complex problems).

Be sure: The overachiever in your team is not a bad person! She aims for only the best for the company and product. Of course, to her, it seems that she does it very well! Remember, you are not enemies or opponents, but teammates who need to figure out how to work best together and achieve sustainable success (and fun)!

Step 1 – Out of your comfort zone!

Well… not (only) the overachiever is the reason why change needs to happen. What does Michael Jackson say again? Start with the man in the mirror! “If you wanna make the world a better place, take a look at yourself and then make a change!”

Speak up, take action, demand change, to improve communication and vary methodologies, and don’t fall into the dangerous pit of self-pity and couchpotato-convenience. See this paragraph as a start for your journey, for letting your team grow together, a bunch of equals. The team needs someone like you. You will be the one who must be demanding change, if your Scrum Master, Product Owner or Lead doesn’t do it! It means, if not you, no one will. The fact that you feel/ realize that this might be or become an issue in your team, you are the chosen one.

But how, you ask? Expect and demand baby steps! There will not be a “big bang”-change and everything is “good”: One step after another. Even small changes can have a big impact.

Step 2 – The (Scrum Master) Talk

I know, the Scrum Master is not holding any leadership position and yet, she is the one who should facilitate and host team gatherings and meetings. She is supposed to take care that exactly this does not happen. Her influence is limited by the willingness of the team, so give her reason and solid ground to work on equalization within the team. Maybe she is not very experienced yet, or she also just accepted things how they are (aware or unaware of what it means). You should find the talk with her about what she thinks about the situation, and what you can do to lift up the team spirit and sustainability! There are many things she can do, to give everyone the change to commit their ideas, opinions, and qualities.

Ah… and by the way: Even if it is only you, who feels a bit outside of the system (and everyone else is kind-of ok), you still should make your point to her. A Scrum Master should also be the go-to-person, for a team members issues, and help to get all the potential on the street!

Step 3 – Remind and demand Agile Principles

Do I really have to say this? Agile teamwork is about dialogues and collaboration. Embrace every individual in your team as equally important and qualified, as a potential if not experienced (yet). Collaborate, interact, and get the best out of every single member! See the first freaking line of the goddamn Agile Manifesto: “Individuals and interactions over processes and tools” ( http://agilemanifesto.org/ ). Such simple and undiluted wisdom… It makes me cry every time I have to remind people to think about it. It should be burned in your and everyone’s (developer) brain. It is not negotiable or relocatable. This should be surer than day follows night. Before you try to enable the potential of your team with methods or tricks, consider talking about the issue openly with the whole team. Make them understand why embracing and supporting overachiever-ness means to risks sustainable success. A retrospective meeting is a very proper time to place your concerns! Agile teamwork is based on trust. Give your team (including the overachiever) the benefit of trust and honesty.

Step 4 – Bring in opportunities for good behavior

Train your instinct and get a sense for the right moments to embrace collaboration. In discussions and talks, notice who is silent and doesn’t commit to active collaboration. Encourage them to speak (up), i.e. by actively asking them about their opinion. If you know your team members well, another more sneaky way is, to bring up a topic they are passionate about, make a connection and/or take an opposition-position, so you tease them out of their lethargy (you can also (later) be honest about your evil-genuine plan to get them into the conversation). Continuously place suggestions to collaborate or to do pair programming, because sometimes a little push in the right direction is all that’s needed. Yes, also you as a teammate can do this – no need for a Teamlead, Scrum Master or Product Owner to make those moves.

Step 5 – Remove opportunities for bad behavior

There are several methodologies to give everyone the opportunity to provide their own input and to also let them talk without being interrupted, discouraged, or subdued. Usually, your Scrum Master comes up with those ideas, yet sometimes they also need a little inspiration. Don’t worry. It doesn’t always need to be a big thing. Actually, mostly it can already be enough to request a democratic vote, to let everyone think about something themselves and/ or add their thoughts. But for some bigger topics, you might think of the following two approaches: A neat little allrounder method is the silent brainstorming, with a followed presentation-time. Everyone has around 5 to 10 minutes to make up their mind and write it on sticky notes. Afterward, when everyone is ready and done, each participant gets a limited time to present the sticky notes, and do something with them, according to whatever purpose the brainstorming was about. Like this, everything is limited to a specific timeframe and as you can see everyone provides in the same manner. You will find your team in situations where brainstorming can be of value. Instead of just throwing in ideas (and get overwhelmed by the overachiever), you can suggest silent brainstorming. Something that helped me a lot to manage bigger teams, with a multi-dimensional problem, was the following: Split the team into two- or three-people-groups. Each group targets one part of the topic and presents it to the rest of the team members. If you want more people to provide input to each aspect do the following: Instead of only dividing the team into smaller groups, you also divide the room/ location into different subject-islands. Each island has one subject-host (preferably the overachiever is also a subject-host). Every person/ group spends around 5 to 15 minutes on each island, while the host notes the important parts of the talks/ discussions. After every group talked about every subject, the hosts present the results of the island. This was most helpful at retrospective meetings or to get solutions for highly complex features or goals.

Always remember: You are not enemies, but teammates!

I hope I could give you a little sense of how you can handle the overachiever in your team. Of course, there is no such thing as a clear path to teamwork-city, but if you take my words as a starting point for orientation, you maybe find the right way. Don’t hesitate to comment or write a direct mail to me, when you have any further questions or feedback.

Enjoy, collaborate and succeed!

Soeren

As a Product Owner and Games Producer myself,  I hope, with the following insights, to bring some value to you and your team members. You will learn why sometimes us Product Owners act how we do, and what you can do to improve your teamwork.

I gotta say: there are always two sides to a coin. Success is a team result – work together and you can make great things happen! If you don’t, it’s very likely that you fail on some level – first a bit – later drastically. In this post it may seem a little one-sided, but of course: the Product Owner should also learn how his team works and why developer and designer act how they do, and what he/she can change to improve your teamwork. But that’s content for futur blog posts 😉 So have fun with probably some unconventional, yet pretty honest insights into the world of a Product Owner.

Table of content

1. What a PO does
2. Why a PO needs you
3. Why a PO disturbs you
4. Why a PO forgets you
5. Why a PO relies on agile ceremonies
6. Sum Up

What a Product Owner does

In my career, I’ve seen a lot of teamwork bloopers. Mostly it all comes down to understanding each other and communicating accordingly. Especially junior-level teams first need to understand how the product world works. Sometimes it may seem like the Product Owner is not valuing your opinion, effort and time, yet I can assure you: we maybe are the ones who are most concerned about exactly just that!

“Would you tell me, please, which way I ought to go from here?”
“That depends a good deal on where you want to get to,” said the Cat.
“I don’t much care where—” said Alice.
“Then it doesn’t matter which way you go,” said the Cat.
“—so long as I get somewhere,” Alice added as an explanation.
“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.”
Alice in Wonderland, Chapter 6, Pig and Pepper

The main goal of Product Owners is to make sure that your work and effort is well-placed, not wasted, not spilled or lost on a wrong path, but creates the maximum value for the user, and ultimately you. To show the way and make sure you are not wandering around like Alice in Wonderland, we try to find the right thing, convincing and powerful. Therefore the Vision Statement isn’t just a buzzword-bingo or brainwash-methodology, but the direction the team is supposed to walk, the common understanding. Sometimes it seems like Product Owner came up with the vision just like that, nevertheless you gotta understand that he’s only trying to put into words, what your organization, society, market and most of all the user needs.

Next to this, probably the most obvious tasks of a Product Owner is to keep stakeholders away from the team and to channel all requests as a single point of contact (SPOC). Because again – We only want you to work on what matters. Mostly stakeholders don’t really know what they want (even though they think differently about that), which makes it even more important to find out, what the actual problem is, to then decide what to do, and what not. That’s why “No” is one of the most important words of a Product Owner. To stay strong and resilient towards everything coming his way, he needs you.

Why a Product Owner needs you

First of all: because you read this blog-post, came till here, and obviously are eager to develop a common ground. Secondly, he really needs your input to work best. In my work I am always trying to make the team understand: I’m not better at programming than a developer, I’m not better at designing than a designer, I’m not better at analysing data than the data analyst, so I need my specialists to give me everything they got, so that I can take right decisions with you.

A perfect example of this is the design sprint. The key objective is to solve a user problem. It technically means to find proof for hypotheses proposed by an idea and then frame a Minimal Viable Product (MVP). Within a week or two, you discover, define, develop and deliver something completely new and finally create value for the user. When the Product Owner puts together the team, it’s crucial to have the right people on board. You got to learn to understand what stakeholders want. This is the right time to show your strategic foresight. Take the technical lead for the creative process and your input can make the deciding difference to achieve success. Bring in your creativity and technical ideas to solve a user problem. You have access to tools and ideas that the others don’t have. Do this and receive standing ovation. The result will be your baby – you will be the go-to-guy, you will suffer when it’s not done well, and you will rise and shine when it’s successful.

But not only in design sprints, we need professional input. Within backlog grooming, refinement or sprint planning give your Product Owner as much feedback as possible, even when he/she doesn’t actively ask for it. Use those meetings as a health insurance for your team unity: mention expense drivers and offer options – be constructive! Within your team, you should consider writing acceptance criteria and user stories yourself, at least when you spot gaps. By putting yourself into the user’s shoes while writing the stories, you raise awareness of the vision and the target persona, additionally, you drastically support your Product Owner. Maybe you even initiate having an Acceptance Criteria-checklist for the team, to encourage and enable everyone to collaborate in this way.

And last but not least: When we ask you for an estimation for a vague story, we mostly need some type of horizon of what can be expected, and we don’t expect an exact calculation – sometimes a guts-feeling is all we want. So it is best to make us understand a tendency rather than letting us stand alone in the rain. Also, explain why it seems unclear, and then we can fill the gaps together.

Why a Product Owner disturbs you

Now you know, the Product Owner values your time but also needs your input. So when you are coming to work in the morning, looking into your schedule and an additional meeting pops up in your calendar – what’s your reaction? Very often I hear something like “Oh, damn meetings, preventing me from working”. If you are not saying this: good! If you do, maybe it’s time to reconsider. When your Product Owner invites to a meeting, he/ she painfully prioritized already, very clearly against his/ her own preferences, because he really wants you to get your stuff done! But your role, as a member of an agile team, is not only to sit behind the keyboard and develop stuff like a coding monkey but to also provide important information and deliver your points of view. Programmers should not encourage the organization to bypass them. If you don’t like specific things in your meetings, talk to your Scrum Master or team, and change it. Maybe others have the same pain points but didn’t come forward yet.

In fact, I meet a lot of Product Owners being “afraid” to distract his team and take them out of their working-tunnel. We know, when you get distracted it takes you time to think on the topic again. Still, when we need important information and technical expertise to determine an issue, we need you. Next time you catch yourself reacting annoyed, show empathy. Another way to handle this and turn it into a win-win, is to agree on how to approach each other: e.g. with Sticky notes, or a sign to set to “need consultancy”, so someone who has a free mind can reach out to him/ her.

Why a Product Owner forgets you

This sounds a bit weird, I know. Yet, there may come the time when you get the feeling your Product Owner forgets that you and the team are also key-stakeholders for the product. Mostly it’s the moments when the technical debt or lack of quality is raising the risk, or you are generally concerned about the decisions. It is important for you to learn how to approach your Product Owner then! The key is to speak in the same language. Write your technical issues as user stories and make clear what’s the value for users if you do it, or the effect if you don’t. The things you care about will be user relevant. Maybe not in the next sprint, but in the mid to long-run. Technical user stories are a thing! They must be split, handled and prioritized the same way as functional stories too. If you don’t speak up in grooming/ refinement meetings, I guarantee, other stakeholders are always shouting louder. Being a Product Owner means people are constantly approaching you, inquiring about new features or bugs. Usually, the team doesn’t do that as frequently as they should. It’s only human to listen most carefully to the loudest screaming person. You don’t have to shout at him permanently, but be verbal and tell him why your idea is good for the user. Technical tasks often address release time, stability or maintainability. You should argument to ship user value faster and have fewer complaints in the App-Store. Lastly, maybe you don’t want to bother your Product Owner too much since you see him/her struggling enough already and you feel sympathy – you need to learn, to still address your concerns!

Why a Product Owner relies on agile ceremonies

Working in an agile environment is pretty convenient, and by applying the best fitting framework, a team gets powerful tools and techniques to develop an amazing product with maximum user value. There are also very important ceremonies no team should miss or stop active participation. I’m talking about retrospectives, sprint reviews, and daily stand-ups. Use them!

It can happen that a Product Owner decides against participating, which is not good in the mid or long term. Every issue has its place and for the Product Owner, it is crucial to rely on some constants within his schedule and to not lose the grip. They are just as important to Product Owners as for developers and designer. So sometimes you need to actively demand the participation of your Product Owner and remind him, that he is part of your team! You can compare it to meditation: You know it actually is doing good to your mental balance, you probably should do it every now and then. Yet, even though it only takes 10 – 15 minutes, it somehow doesn’t fit into your day. You might be happy and thankful when you have someone who reminds you of simply doing it.

Sum Up

So what did we learn today?

• We actually do stuff that is good for you,
• we need you,
• we value your time and opinion,
• and if we seemingly don’t, we need to learn to speak the same language,
• and we need to maintain a common and constructive base, using agile techniques.

All in all, we need to keep in mind, that, even though Product Owners are mostly the only one of their kind in a team, they still are team members and not Englishmen in New York. And yes, sometimes we can be a pain in the ass, but maybe now, after reading this blog post, it is easier for you to understand.

And, dear Product Owner colleagues, if we can’t excite our team to believe in what we do, if we don’t fight for their interests, and not make them understand the “why” behind the “what”, but instead build up walls of miscommunication and distrust – we won’t stand against the competition. We need the team and we need to be strong together.

Rise and shine!

Best regards

So as we sat down to brainstorm about possible projects we came up with one that solves one main issue in the charity-ecosystem, connecting the concept of blockchain with charity – two worlds connected – we called it “Chario” and registered for EXXETAs challenge.

We developed an app for middlemen (Agents) and a web page for benefactors, both connected through a backend that facilitates the data between them. With our system, we enable benefactors to choose where exactly to donate to, then chose one out of several possible donation-types (material or money) to finally trace the donation throughout the process, till it finally reaches the beneficiary (proven by a photograph). After 24hours of creative teamwork, coding, struggling and getting-shit-done, a huge amount of coffee and a 15 minutes pitch to the EXXETA team we were done, and yet we somehow managed to hold on till the very end. Don’t underestimate the pressure you’re feeling and the effect of sleeplessness on your nerves when you didn’t sleep for around 36 hours, facing a pitch in front of 200 people. Somehow, we gathered all our inner forces and simply just performed. The rest still seems blurry somehow: We didn’t expect to win anything, so we were surprised, yet very very happy and thankful as Matt was standing on the stage, shouting out our name, saying we won the Category-Price “Connect the Worlds”:

Not knowing what huge effect this prize will have on our team experience and future plans… in this blogpost, I will try to give you a small insight of what we learned. Be aware though, this is just one brick on the wall. There were side-stories and a lot going on between us, the other participants, the amazing EXXETA team, Berlin, clubbing, cocktails, accommodation issues, and so much more… all in all, this was a trip we’ll hopefully never forget.

What happened so far?

Obviously, our EXXETA-Go-To-Guy Matt couldn’t wait to get the workshop started, so he directly added Danny and me on LinkedIn. Quickly we exchanged email addresses and phone numbers. We agreed to make a call with all Billige Plätze on Skype which turned out to be casual and welcoming, our excitement grew. In the aftermath I can only assume how much energy went into planning and organizing the workshop, in the background Matt and his colleagues must have started right away – impressive – what an eager team! Soon they sent us successively more and more info about what’s about to come. The last notice was, that we should re-prepare our pitch from the hackathon. Like most of the projects born at hackathons, there has no further work been done for Chario, even though it was, like all the times, also a project we’d like to keep working on… Since only Dominik, Leon, Danny and I attended the hackathon and won the price, it was more than just nice that they also invited the rest of our real Team “Billige Plätze”. Hence, all of us are on the way to Berlin right now, looking forward to the next days and experiences.

And as we are on our way to Berlin now, I’m getting started with this field report, my diary of our experience of the workshop with EXXETA…

Who is EXXETA?

With more than 750 employees EXXETA AG is a big international player in Technology Consulting for the Energy-, Automotive- and Finance sectors. They have several offices all around Europe, most of them in Germany. The team that invited us is known for innovative and unconventional, yet successful methods and measures to get things done. They are situated in the WeWork Coworking office in Berlin – next to the Sony Center. During the workshop, we got to know a few colleagues of Matt and were amazed by the casual, young spirited, yet professional style.

Day 1

The Factory

We were a group of 12 plus the EXXETA coaches. First stop was the Factory. The Factory is an amazing Coworking space for innovators and startups that grow a community by carefully choosing who joins the network. Not only are the offices well designed and furnished, but also it scores with features like a ball pool, foosball, huge kitchen with coffee for free, space for networking and getting to know like-minded people. There we met the IoT and Blockchain company builder Next Big Thing.

Meet&Greets

Next Big Thing – What does a Company Builder do?

Next Big Thing (NBT) specializes in IoT and Blockchain startups to give them a quick and smooth start. This is especially helpful when it comes to startups with hardware-based innovations. NBT supports a startup not only with access to a big network of startups and investors, but also pays you a fair monthly salary and helps you to deal with topics like IT-security, technical certification and standards, legal regulations, bureaucracy, HR administration, accounting, marketing, pitch-coaching, recruiting, office infrastructure, workshops and much more. Also, they have a highly-specialized senior developer team, supporting you with additional operative workforce to get your product onto the market. They developed a program called “Venture Design”, where NBT leads you through all the necessary steps for building your own company. My key learning of this visit was, that all of their startups ended up with another product as they actually began with. Therefore, they rather decide on a team or person, than the idea that got pitched in the first place.

Entrepreneur Alexander Barge

Next station was lunch, where we met Alexander Barge. Alex is a highly experienced Entrepreneur and deeply integrated into the Berlin startup scene. There we had the opportunity to place our questions in a personal atmosphere and get first-hand advice. So after we got introduced to the complexity of founding, Alex managed to motivate and encourage to start something new, thanks to his enthusiasm and up-beat. As a CTO and Co-Founder himself, he made it clear, that you can “just start”… of course it is a lot of work, and you will never lose that bad conscience of “actually I should be doing something” whenever you’re not working, and eventually you’ll fail at the beginning – but there will be progress, excitement, a lot to learn and eventually a chance for success. It seemed a bit like what I told you in my previous blog post (“How to start and learn coding”) – all you need to do is get your a$s up, start and stick with it as much as possible. So next to the delicious food we dined that fantastic enthusiasm.

Blockchain Lab at GIZ

Since the Chario-Concept was driven by a non-commercial idea and we mentioned the idea should be realized with blockchain-technology, the next stop was the Blockchain Lab at the GIZ (German Corporation for International Cooperation GmbH). Franz von Weizsäcker and his team are trying to find sustainable use-cases for blockchain technology. With the technology of Blockchain, it generally feels a bit like there is a solution without knowing the problem it can solve yet – so it needs specialists like Franz(s team) to find out where to place this technology without risking an alienating effect.
We asked what they think about our idea and if it seems realizable. The answer made clear, that in the charity-ecosystem there is a big resistance towards change, especially when it means that i.e. middlemen might earn less than before – yet, the use-case of connecting blockchain-powered traceability with donations is very promising and powerful.

After a short break and retrospective come-together, Matt introduced the first canvas to get a business model sharpened.

Working with the Value Proposition Canvas

We started with a canvas which is supposed to help to focus on the user’s needs and then find possible solutions. Here you can find a nice and simple explanation of the canvas:

How we did it: Field by field, we were timeboxing silent brainstorming-phases of around 3-5 minutes, where everyone wrote the ideas on Post-Its. Followed by putting those on the canvas, one by one. Each session continued with a short discussion about discrepancies and different opinions until we go to the next field.
We were working through the canvas in this order: Jobs => Pains => Gains => Pain Relievers => Gain Creators => Forming the products and services. The moment you are done with the canvas it is useful to go over it again, cluster it by topics, and at the end prioritize the features to decide whether it is an essential part of the Minimal Viable Product (short MVP) or not. Here is our result – a bit messy, and yet we all like it:

Our First Little Pivot

Within this process, we figured out that we got to change something about the product-idea since there are two main issues

• Issue one – Transparency: Why would non-governmental organizations (short NGO) and their middlemen cooperate with us to make the effort and implement transparency features in their processes?
• Issue two – Proof of good work: How can we know who needs the donations?
  We learned that a service/ system or product that solves all the issues would be too big as a start, so we wanted to pin down possible features for an MVP.

And even though we found possible solutions for those two issues, we realized that none of us are somehow eager to dig deeper into any of them. Motivation is key! So based on our first result we decided on developing a system that motivates future benefactors and helps NGOs to raise more money. The idea went a bit into the direction of something like payback for NGOs, but better… of course 🙂

After an exciting first workshop day, the team ordered pizza which got accompanied by insights of EXXETA from the development team leader Sébastien Jelsch. He was stating that, if you don’t want the insecurity of a startup, yet work alike, in a team of people who want to make a change, you may check out what’s in the job listings on their page 😉

Day 2

The second day was all about getting our first business model-draft done. After a short tour through the amazing Coworking office WeWork, we got to work, more focused than ever, quickly filling up the Value Proposition Canvas and sharpening the concept.

Business Model Canvas

The Business Model Canvas is a lean method to nail your business model down to its core. Find out more about the canvas here:

We easily went through this canvas. The product and the organization around it was clear to us, so there was hardly any reason for discussion. The Value Proposition Canvas was a perfect preparation for this one. Here is our result:

The next step would be to go over it and distill the core out of our brainstormed-content.

What is the LVLX Summercamp?

During our lunch break, Matts boss came around, wanted to know how we like the workshop and told us about the LVLX Summercamp. It is a paid six-weeks-program for (mostly) students who want to focus on their idea or product and get supported by EXXETA and their “high-society”-partners. If it wouldn’t be so entirely impossible for us to take part, we had not hesitated one millisecond. I’ll be following the outcome of that workshop, knowingly that all the potential they gather and own, there got to be some pretty impressive results.

One Metric That Matters (OMTM)

To get back to work Christian Grimm from EXXETA gave us an important side note: Focus on the right thing is essential for the success of all the phases a startup goes through. And the argumentation is simple: You don’t have a lot of resources and time, so the only way you can get more of each is by using the bit you have for the right things. Defining one metric / KPI can drastically help to consequently align the work and focus of a team. In the beginning, it’s the key to look for “softer” or money-unrelated KPIs, like positive/ negative-feedback-quota or percentage of MVP-features, developed, rather than sales or ARPU. If you are interested in reading more about this, I can really recommend this blog: Lean Analytics Book.

The Timeline

With this at hand we managed to finish our first self-developed Business Model Canvas, and so we moved on to the last part of the conceptual day: the timeline. Nearly as easy as it sounds, you define three time-intervals and decide for each of those phases your goal, invest, team size, OMTM, hypothesis, important tasks, open questions and possible obstacles.

Intrapreneurship

The following talk of Philipp Stork was about a question that big companies started asking: “Why can’t we be as quick as a startup?” The phrase “Intrapreneurship” indicates that those companies should develop an entrepreneurial mindset within its employees and empower them to pursue their demand for creating something new, in the name of the employer. This sounds like a pure win-win situation, you maybe think? Research shows that there are companies that fail to implement a startup character within a motivated team, or sadly still don’t want to see this “unconventional” method as a valid solution. Yet when a company goes that way and really empowers their Intrapreneurs, there is a chance of success.

Entrepreneurship

Since most of the meet&greets, talks and tasks of the workshop were about sharpening our concept for a possible startup, in his keynote, Matt managed to find the right words about what it takes to be an entrepreneur. He broke it down into three main-skills:
1. Think outside the box: Because there will be moments you couldn’t foresee, and you have to react, there will be problems you have to solve creatively and pragmatically, you got to be able to improvise and surprise!
2. Be focused: Just as mentioned before – use your resources effectively. As an entrepreneur you can only set small accents, yet if you place those correctly, you can make a change, because you have the freedom from all the internal politics, bureaucracies, hierarchies and everything else that slows down bigger companies, but a big chunk of motivation, team-feeling, including the responsibility to quickly launch your product with the available resources, and beat incumbents to market.
3. Don’t get discouraged: Especially after the first few days / weeks it comes again: The daily business – just like in a relationship, you will have to make the transition from “having a crush” to “being in love”. On a journey as a founder, you meet a lot of naysayers just as sure as failure will happen. This should never be a reason to think about stopping, but to stand up, learn from mistakes, filter between good and bad advice and have the courage to learn and maybe change a plan quickly.

There is plenty of literature about how to get started with your startup. Here is a Must-Read for anyone who is actually thinking about it: Startup Playbook by Sam Altman.

Afterward, we sat down and enjoyed a wonderful cold beer in the Coworking space WeWork, where we stayed a bit longer, till we finally had to leave, and the evening celebration got started.

The Sum Up

So what do we take away from this two wonderful workshop-days?
First of all, we gathered a lot of insights when it comes to founding, depending on what product you work on. Secondly, we developed an idea that we might pursue in the close future. Thirdly the EXXETA team managed to pack our bags with the right tools to work on further ideas, what we’re going to try out at the next hackathon or other future projects. Last but not least, we got a glimpse of the Berlin startup ecosystem and found a lot of new friends – all of us were purely amazed! We, the team Billige Plätze, had a very fruitful, intense and important time with each other, bringing us together more and more. Who knows what maybe getting started thanks to this experience…