Tag Archives: saas

GenieBelt’s great 2017

I realized a while ago, that on my blog I have done only sporadic updates on how things are evolving with my own startup, GenieBelt. Too bad, because things have been more than normally exciting especially the last one and a half year, and the journey so far is a good story of persistence and ambition, which I think startup interested people can learn from.

As I wrote back in 2013, the starting point for GenieBelt was that Construction is a huge industry hurt by quality & cost problems, and it seemed straight forward that modern day technology and product usability focus could help massively – and on the back of that we could “easily” build a great company. Things turned out – as you can expect – to be a bit more complicated. But hey, that’s what makes these journeys entertaining and educational.

First of all, it took us three long years to go from idea to a beta product that really worked well for customers. For three years we walked through the desert having endless product iterations and strategy discussions. Tenacity, ambition and a great internal partnership made us get through it all. And maybe also having a bit more luck than un-luck!

We have been fortunate, that a number of visionary customers understood, what we tried to do and wanted us to succeed because they felt the pain themselves from communication and coordination flows not working in Construction. They gave us one of the the most valuable things for an early stage startup: hands-on, detailed and credible product/use-case feedback. But even with valuable data on the intricacies of Construction workflows, then it took us three years to get there. Why?

Construction is not only a huge USD 10 Trn. industry, but it is also a complicated sector to understand, e.g. the many different roles (clients, main contractor, multiple subcontractors, adviser this, adviser that, etc.), all projects having different participants, the participants changing roles between projects, etc. etc. One of my partners, Gari, calculated that there are 70 Million different kinds of Construction projects that all have their unique set of characteristics. So of course there are challenges in figuring out how to make a platform, that can tie things together without getting too complicated.

Another of the big challenges in Construction, is that 80% of work/costs are used at the Construction site, but it is at the office most decisions are taken, and where the involved parties have digitized most of their processes. The link between site and office is broken, and that is one of the main sources of the industry’s trouble – and this goes for almost all of the 70 Million permutations. From the beginning, we focused exactly on the “site-to-office” link, since that is what no-one has fundamentally solved. The established solutions targeting Construction are PC-era products that does not cater for a good mobile experience. New “ConTech” startups are using the mobile revolution to close the gap in various ways, and we have followed our own, unique path.

What started to be clear for us end of 2015, and more and more so during 2016 were a number of learnings, that fine tuned our product and commercial strategy:

A: Use a visual expression that is familiar. My first idea for how we should structure and visualize the data flow on a project was influenced by the kanban model also used by Trello. However, when we got our product wizard, Bob, on board, he came up with an obvious idea that has worked incredibly well for us: in Construction you are used to Gantt charts, so use the same structure for all the communication, i.e. build a living, dynamic Gantt structure for how you communicate and share data. Totally logical when you are being presented for it the first time, but someone needs to get the idea and execute on it.

B: Clarification of our Why/Product Road Map. From the beginning, we talked about improving workflows on construction projects and over time build some kind of analytics around this. In the beginning, I personally positioned  our solutions end-result as “Construction Managers need to look good and sleep well”, and that is still an effect of our offering, but over time we came to a better way to describe what our platform brings: transparency, accountability and overview to Construction. So much of the problems in Construction is because the participants don’t know what’s going on. They know what the plan is (or at least what the outdated plan said), but they don’t know actual status/progress update. Designing a platform that creates transparency on progress and performance would be a tremendous achievement. This is not only about launching a new solution to the industry, but it is becoming a thought leader on how the culture in Construction regarding collaboration and communication needs to change. We need a behavioral change and our solution and go-to-market approach should facilitate this in the most user friendly way. This is a much bigger challenge, but building the platform that can achieve this inherently also brings bigger benefits to Construction than just adding digital tools to an existing, yet imperfect process. Good – our ultimate ambition is to build a great company that can change construction for the better, and the opportunity is right in front of us. We are not just digitizing an existing process, we are facilitating a real change on how to manage construction projects. This deeper insight pushed us forward.

C: Shifting customer segment focus. Originally, we believed our core market would be small & medium sized ( SME) main contractors. In our journey, we realized that even though there are clear benefits for all participants in the construction value chain, then the part of the value chain that most clearly has benefits from more transparency and accountability in construction are the Clients & Developers. The Main Contractors also benefit, but they are at the same time more nervous for the effects of transparency, therefore some of them are not ready to change. The most strategic thinking General Contractors get it, but some are still focused on preserving the old and broken habits of the industry. We can therefore see, that even though we sell to all participants, then the majority of our customers are either Clients/Developers or those Main Contractors really willing to modernize and improve. And our customers are mainly mid-sized and big, because they are the one’s that best understand the need for systemic change. The smaller players will join as the industry changes, but it will be the mid-sized and bigger ones that will push the hardest for this change.

D: Commercial strategy based on hybrid sales approach. As a starting point, we assumed that we would use online channels to generate leads, and that the majority of those leads could be closed via low-touch channels. As our product- and customer focus evolved, we can conclude that our commercial strategy de-facto is much more of a hybrid. For sure, we have shown a very good ability to create traffic and leads online (and we will further improve that), but most of our revenues are closed with a sales force working online or in the field, i.e no touch only has a marginal impact on our revenue growth. Our commercial strategy will be a hybrid model of no-touch, low touch and some high touch sales, which is absolutely fine, since our unit economics are very healthy (MRR pr customer multiple times higher than anticipated helps a great deal), and we have people on board that have experience in scaling commercial organisations.

There are obviously many more details in the story, but the above four adjustments to our original battle plan have been pivotal in getting product-market fit and a commercial strategy that accelerated GenieBelt.

There have been plenty of errors along the way. One of the classical errors we have made is to let the product stray off course when the main direction had problems getting traction. We did a bit of snagging features in the beginning which we should not have done – closed down again. We did a bit of documents & drawings, also shut down. Classic start-up stuff when you get impatient iterating on your core use case.

So plenty of problems, but ultimately we have come far even though we of course know there is still a long way to go. Some of our achievements really make us proud, and they are part of the foundation for the coming years.

1: Our Ambition. Both the original founder team as well as the partnership team we have build over time is very ambitious. For most people it must sound crazy to have a small group of people deciding to change a big industry – but building a Great Company that can do that, is exactly what we want. One of the effects of that has been to deliberately not build the obvious products, that other ConTech companies built. The ConTech software startups have in general focused on snagging, health & safety and other products where an existing workflow is digitized. That is smart, since it’s more straightforward to design the product, and get customers engaged. Quick pay-off, and it of course moves Construction forward. But the basic problem of transparency, accountability and wider collaboration is not attacked head-on to the same extent, and therefore the transformative nature of the solution is not as the platform GenieBelt is offering. Our ambition meant we had to do something that no-one had done before: creating a platform that “connected site to office, and data to decision makers”, and that took longer time. But now that it works, then it is a transformative solution, more uniquely positioned and more significant in it’s impact. And better chance for building a truly Great Company. Having this ambitious mindset caused trouble the first three years, but now it is paying off.

2: Our Partnership. Today GenieBelt is run by a partnership of five guys (and yes, sorry – we’re all men!). Three Danes, two British. Two with Construction background, three with none. Four with good sense of humour, one with non-classified and very troublesome sense of humour. Four with plenty of startup experience, one has GenieBelt as his first startup. Three in their 40’s, two in their 30’s. Three that are hunters, two that are not yet, but secretly wants to become hunters. One and a half who are a football fan, three that just doesn’t get it. And all five of us are fathers with daughters and sons. So, we are a mixed bag, with very different backgrounds and mindsets. But we are glued strongly together by our shared ambition & vision for GenieBelt as well as a strong respect for each others professional and social contribution. We have already seen plenty of difficult moments, and we have come through all of them getting tighter in the process. One of our achievements is, that we have been able frictionless to change CEO twice, first in the initial year from me to Gari, and then in 2016 when we started building scale and commercial activities from Gari to Ulrik. Every time we have come out stronger. Personally, the partnership is a big reason why I enjoy the GenieBelt journey, and it is essential for my belief that we have a chance of achieving our ambitious goals.

GenieBelt partnership September 2017 when we celebrated taking an important decision – no further comments!

3: Our Culture and Organisation. With solid roots in our partnership philosophy, we have build our organisation from 12-14 people one and a half year ago to now 40+, based mainly in Copenhagen, but also London and Lodz. As is the norm for startups in Copenhagen, our organisation is very international with nearly 20 different nationalities, so at HQ the Danes are outnumbered. When growing the team from a small group of people to platoon sized and beyond organisations typically experience “cultural shakes” (more about that in a blog post some other day), and often the culture changes for the worse. To counter this, we have been very value driven. Due to some of us experiencing growth journeys before, we have focused on steering through the shakes to come out on the other side, with an organisation that is well glued together. One of the things we have done is to define and be explicit on our values; CotB, BIW, BoB, Respect and NoBS – values we try to stick to when taking HR and strategy decisions (NB: humour is deliberately left out as something we value, since too many laughs at the office has a tendency to create inefficiency and lack of focus – and is in general boring). So far we have succeeded in maintaining a vibe good people thrive in, and we intend to work hard to secure this as we move towards a company sized organisation, because the soft assets are usually the hardest assets in the long run.
Random GenieBelt’ers 2016-17

Four and a half year in, but it’s still early days. We have hardly scratched the surface of what can be achieved, but the snowball is rolling now. Together with many good people among Main Contractors, Subbies, Construction Clients, Developers, Advisors, other ConTech startups and Construction Industry influencers we are certain that change is now finally coming. We can all look forward to better housing, infrastructure, office space and anything else that the fascinating Construction industry produces. On time, on budget, quality spot on, less waste/environmental impact/injuries – what’s not to like!

Construction of Strasbourg cathedral, Alsace, France, engraving after a pen and ink drawing by Theopile Schuler, 1821-78, French Romantic illustrator and painter. Strasbourg Cathedral or the Cathedral of Our Lady of Strasbourg was begun in the 11th century and completed in 1439. The drawing shows the flying buttresses outside the nave and many medieval construction processes. Picture by Manuel Cohen

 

Public purchasing regime as a barrier for the building of tech clusters

In most countries there are plenty of examples of the State (and it’s associated public organisations such as Municipalities, Regions, etc.) buying IT solutions that ends in a disaster. In Denmark we have a pretty long list of such failed, publicly owned IT projects.

Everybody that has been part of IT development knows, that innovation doesn’t always work, and sometimes it just goes wrong. That has to be accepted as a starting point. However, there is something else that our politicians and public servants needs to be aware of before they launch tenders for new IT systems: the purchasing and development methodology is often wrong. It is not only bad project management that causes the issues, but also the way the projects are laid out from the beginning. This causes not only bad use of our public money as well as bad solutions for all of us, but it also undermines the objective of building tech clusters, for example in relation to welfare technology. In Denmark, where I reside, our last left wing government wanted welfare technology to be a Danish export success, and so does the current right wing government, so the local industry receives government grants. But grants is not the key, customers is key.

(NB: I have invested in a few companies that sell to the Public sector – e.g. Sekoia, Famly, Peergrade as well as my own construction related company, GenieBelt – but I hope my arguments clearly shows, that my agenda is not entirely selfish).

To understand my point about how the public purchasing processes are hurting us all, then we need to look at how the projects that the State et al are buying are normally organised. They will almost always use the “waterfall development process“, i.e. first a very loooooong specification is made by analysts, then this specification is shipped over to the developers who then start coding for a few years. The actual development process will be structured in some phases, but fundamentally progress is seen as flowing steadily downwards. It is sequential and not iterative. Several years after the first notes on the specification it is finally delivered to the users.

More and more often this is not the right approach for developing systems. There are multiple problems, the first of which is that often the detailed specifications are totally out of tune when the project is finished many years later. Both user needs and technology has moved on.

In the tech startup world this is pretty obvious. After the good old .com days we have increasingly used more agile development methodologies with emphasis on iterative processes. We will try to find the MVP as quickly as possible. We look for the UX and feature set that as a minimum gives a path ahead in terms of how to achieve the core benefit of the product. Often the hypothesis is changed multiple times in the process, my own journey with GenieBelt is a good example of this, where we on a monthly basis would ask our selves, our data and our beta customers if we were on track. After the MVP we will move on, and iterate towards a commercially viable MVP, etc. etc. Always iterating, driven by monitoring actual engagement metrics, always prioritizing the important stuff and cutting out all the nice-to-have clutter. It is impossible to wait 5 years and many Millions of EUR/DKK before we know if we have something that works.

There is a lot of advantages of this model, e.g. we will quicker get to the core of the problem that needs to be solved, and we will quicker start to challenge various hypothesis on what the solution should be. Less risk of spending years of coding on something that makes no sense. Furthermore, the ultimate solution will in general be better, because the specifications are constantly being updated based on real user engagement, and not what an analyst believed some years ago. And that is also the way we should build welfare tech solutions to the public sector.

Why are not more public tenders based on this development model? I don’t know for sure, but there is some rigidity in the system. Also, the big and well-established players in the market (which in Denmark would be KMD, IBM, CSC, etc.) has an interest in keeping the public sector in this development cycle, since their entire business system is tuned to these kind of processes. But if it doesn’t change we will stay where we are: huge specifications that are partly irrelevance, year long projects that are delayed and too costly. The big guys should learn from the small innovative startups to earn their right to keep on serving our public sector.

But the problem is actually even bigger. In our part of the world (Denmark/Scandinavia/Nordics) we have a unique expertise in welfare technology. This can be used to create internationally leading tech companies, that based on the (small) home market export our state of the art solutions to the rest of the world. But one of the pre-requisites of this is, that we actually have a home market. A market where we fine tune the commercial PMF, where we start to build scale and recognition. If we can’t offer our startups a home market, then it is very-very difficult in the welfare tech space to build an internationally leading company. Since the public sector has monopoly power on big parts of the welfare system, then we need politicians and public servants in charge to recognize this issue, because otherwise we are missing a significant opportunity – on top of making it worse for our own public sector.

A concrete example will make it obvious what we are dealing with. 3 years ago, the newly founded company Famly launched a platform for communication and administration in the daycare/kindergarten/nursery sector. PMF was found, the team started selling after a while, and now they have sold to more than 200 institutions in Denmark. This summer Famly received a couple of Mio. EUR for their growth in UK, DE etc. There are other players in the market, but Famly is the Scandinavian company moving the fastest due to a super slick product with some of the highest engagement metrics I have ever seen.

All looks pretty good, because there are another couple of thousand institutions in Denmark alone, which will be a solid home market to support a growth journey where tens of thousands of these customers could benefit from the platform in the coming 5-10 years. But then something happened last year: a public IT company (Kombit) decided that it was about time that the Danish municipalities should have a solution for their nurseries. Instead of asking the existing providers on the market, they instead made a looong specification, and have recently put the project up for tender. In total the project is planned to last 5 years, and costs several hundred millions of kroner (7,4 DKK = 1 EUR). Almost all Danish municipalities have signed a contract supporting this project, even before the specification was finished. And I am sure, the municipalities did it without really checking the market.

So now this market will freeze, because the municipalities (which are 90%+ of the customers in Denmark) will wait until 2020 (!) before they can get a solution they need TODAY. And then they will pay a lot of money and get a product I bet is worse than if they had asked existing providers to start delivering TODAY. Plus of course a monopoly has been created for this kind of solution since all the municipalities decided they would be part of the tender.

On top of this, the existing startups are excluded from the tender, since it is stated that in order to be considered as part of the tender, then a provider needs to have DKK 250M in revenue, equity of 200M and be profitable over the last three years. They might as well have written: “all startups, fuck off!”. Sorry my bad language, but I am a tax payer and voter in this country, and it is demotivating to see this unfolding.

I dare to argue, that if the municipalities today choose to buy from the existing providers, then they would not only get a solution immediately that would provide clear value, but they would also ultimately end up with a better solution by 2020 at a lower cost.

The public sector in the Nordics is about half of our economy. If the public sector does not design purchasing processes that are supporting the development of tech clusters, then we are shooting our selves in the foot. In some sectors this is more important than others, in welfare tech it is totally essential.

UPDATE: just to be clear, there are plenty of good examples, where the public sector in Denmark/Scandinavia works well with small, progressive companies. In GenieBelt we have several forward looking customers among the municipalities as well as government agencies, and Sekoia could not become a success unless many municipalities/kommuner took a bet on the solution a couple of years ago. The point is, we need much more of this!