Building Uber for Software Developers - 12 challenges in scaling market networks
Hackerbay is a market network for software development. We are building technology to change the status quo of software development.
Our mission is embedding hacker culture into organizations. We are fighting against the outdated IT departments and their partners in crime (large professional service companies, computer science departments at universities & millions of outsourcing shops) by leveraging the Silicon Valley mind-set of hacker culture: Business over tech.
Hackerbay received funding & mentoring from Palo Alto based VC firm NFX, the inventor of the term market network in 2016. If you want to learn more about it follow NFX Guild and James Currier.
This post open-sources our challenges in scaling a market network in the service industry. We share the learnings and experience to move the entire market network industry forward.
Challenge 1: Disruptive innovation vs. incremental innovation: customer journey modificiations
Back in the days Garrett Camp and Travis Kalanick started Uber to change the status quo of the taxi industry. Uber’s technology was used to provide a way better, cheaper and more reliable solution to the same problem: Moving from A to B in a city. If you refer to the first pitch deck of Garrett Camp https://medium.com/@gc/the-beginning-of-uber-7fb17e544851 you directly notice that they didn’t wanted to build a better taxi service, but to change the industry.
When we started Hackerbay, we knew that the industry of software development is cancer for clients and great developers. There is no transparency and there is no efficiency. The end-user experience is generally horrible and not measurable. Hackerbay is about fighting the traditional IT department, just like Uber is fighting the taxi industry.
The target group of a market network are small and midsize companies, who want to improve their daily business. We found out very early, that if we want to change the status quo of the industry, a market network is not the exact right business model. The goal of a market network is to improve the general industry by moving the industry from an offline business to the cloud. Your mission is that you help professionals spend less of their time with administration (proposals, invoices, etc.) and create positive network effects. Your job is to improve the quality of the industry incremental.
The reason, why it is way more complex to disrupt the industry in a complex service then Uber is that you are changing the entire customer journey. The customer journey of a ride (San Francisco Mission to San Francisco Market Street) is still a defined, clear customer journey.
At Hackerbay our first idea was to order an app via chat instead of a meeting. So we fundamentally changed the customer journey and economics. As a consequence of changing the customer journey at the first step, the complexity of the software development process increased and the customer journey changed along the way of a project. As a B2C company like Uber your job is to improve the customer journey by providing more value (lost phone, faster pickups, cheaper prices). As a B2B company your job is first of all to reduce complexity for your customer, not necessarily providing more value.
As a consequence, if you don’t understand the customer journey 100%, how can you model a less complex customer journey in software (pipeline software) for 1000s of small and midsize companies.
We are still changing the status quo of the software industry with Hackerbay, but the disruptive element, made it clear to us, that moving all nodes to the network is not possible for us at the moment (August 2017).
Challenge 2: Complex industry information structure vs. simple information infrastructure in services
There are complex and less complex services. A pro-soccer player is valuable, because he has a lot of experience and he is really special in a certain field. The pro-soccer player can’t be changed easily for someone else. Uber, on the other side, is an easier service per se.
But even in the professional service industry the range in complexity of industry information is not the same. We noticed with software that the information layers and variables are nearly infinite. Moreover, since software is fully created in the minds of people and was just invented in the last century, it has a way more complicated information structure than e.g. architecture (squaremeters). Moreover, because of the global & decentralized nature of the software industry it is really hard to find standards and norms agreed on by a certain authority. In the legal industry court decisions matter and universities. In the software industry the main authority is Silicon Valley best-practices. But those standards are not normed, because corporates don’t have the time to unify and standardize.
If you are choosing to move into a market network a major challenge is to see, if you can crack the data and information structure early on. If you can’t structure the data information structure, it is really complicated to improve the status quo.
On the other hand, at Hackerbay, we were working really hard with data analysis to have more information on software innovation than anyone else in the world. This could become a competitive advantage in rolling out a feature for the industry. Unfortunately one of the main innovations in the software industry is because programming languages and developers and services are constantly competing for a better way. This leads to even more innovation. As a consequence a central transparent authority will probably not be agreed on and even if it’s agreed on, why should people not find ways to arbitrage away competitive advantages.
TLDR: watch out the data information structure of your industry;
Challenge 3: Tangible vs. intangible services
Services can have a tangible result or an intangible result. So, for example the service of a photographer is a tangible result: a series of photos, which can be uploaded, shared, consumed, printed.
Also, take the market network IVY (www.ivymark.com). Ivymark helps interior designers have better busineses. An interior design is a highly tangible result, not only for the client, but also for interior designer. It is tangible also for third-parties. Every human has a general understanding of what is interior design and what it is not.
Software development is way more complex, because it’s most of the time intangible.
Building a market network for software development faced us with the challenge that the service of building a back-end or scaling a server or implementing a third-party API is intangible. You can’t touch software. Moreover it is very hard to visualize in a compelling way.
At Hackerbay we decided that we need to move the market network towards visual products like mobile apps (screenshots) or websites and limit ourselves in the market, because of the attribute of a visual front-end. Moreover we decided to focus on marketing applications, because of the beautiful user experience. If you already can’t touch software and you can only see it, at least it needs to be beautiful.
If you look back at the history of ecommerce, jeff bezos and Amazon are so successful, because they have chosen the right category: books. It is tangible and nearly all books have a cover (photo of a book cover makes a book tangible). Virtual goods and digital services only got mainstream with the success of Apple AppStore. As a consequence it is not impossible to move an intangible service to the cloud, but it’s a challenge.
Challenge 4: Differences in end-service customer: B2B vs. B2C
All market networks are B2B products, because a small/midsize company pays to use your service. But the small/midsize company can have B2B or B2C customers.
Take HoneyBook as an example: There is no business, who organizes weddings, but it’s consumers. On the other hand, Hackerbay is 99.9% B2B. Consumers don’t buy apps. If consumers buy apps, they are already small businesses. Most successful software vendors are dealing with large clients and long-trusted relations. As a consequence, there are some differences listed here:
- Power balance between B2B and B2C is different
- B2B complexity of procurement processes (online payment)
- Political problems vs. rational problems
- Many decision makers in B2B vs. single decision maker in B2C
- Collaboration in B2B is mostly a negative network effects. Every new person makes the other people worse, because of the internal complexity of a corporation.
For us it’s not possible to say today (2017) that a market network in end-service B2B is easier or harder than a market network in B2C.
Challenge 5: Defined timeline vs. undefined timeline in service
When you are scaling a market network the nature of the service processed by the network can also differ on the variable, if there is a defined timeline to the service or if there is no timeline.
Take HoneyBook for example. A wedding has a fixed date, people all work towards this day. Wedding day has to be the best day of your life and it’s fixed several months ago. The event photographer can’t say that he might come a week later or not show up at all.
Software projects are without a fixed deadline. 90% of large independent software vendor projects are late. At Hackerbay, we defined fixed timelines for our clients, developers and us in early 2017, which was another variation to the customer journey, but increased quality KPIs.
An alternative to an undefined timeline, but still a high service quality, is a very clear defined service (scope). So, for example at Uber the timeline is not clear, because the ride could be affected by traffic jams, etc. But since the service and the pricing model is clearly defined, the complexity is controlled.
At Hackerbay we introduced the feature of the offline workshop in order to get fixed timelines elements into the service value chain. Those timeline elements now define different stages of a project and therefore making things more measurable.
Currently, we are experimenting, if we can move workshops entirely online (by doing Zoom/Skype sessions) instead of in-person meetings. If this works, the timeline issue can be re-engineered by setting up artificial timelines into the pipeline process.
Challenge 6: Static vs. dynamic service portfolio
We noticed a further challenge in building pricing engines and proposal tools for our market network, it was a very dynamic portfolio of services.
Of course, in all market networks and service industries there is change. A chair looks different in 2017 than in 1960, but it’s still a chair.
But if you look at the dynamic new creation of new categories and demand pikes and changes in software, the complexity of the software (and the data wrangling) is way more complex.
Take for example the Google Trend graph for autonomous cars. It takes off, but what is exactly an autonomous car. So each variable (Lidar, Autopilot, Python, Deep Learning, …) is changing as well.
Or another example is the graph of “blockchain”. In software development there is now a demand growth for Blockchain. This dynamic in service portfolios is not only complicated because of the talent networks, but also for your software, because it needs to be easily changeable and then curated.
When you are building a market network, just try out Google Trends (trends.google.com) and analyze the graphs of categories, features, attributes. This can help you build the data infrastructure. Dynamic elements are more complex than static elements, but of course you need to follow the market standards in your industry/vertical.
Challenge 7: Talent networks =! network effects
A major challenge and learning at Hackerbay was that there are no direct network effects on the talent network. Each developer is not making every other developer better. A talent network is not a network effect.
This learning is essential to the defensibility of the business: The power of market networks is because of network effects and if you don’t have a direct network effect on your users, it is hard to scale up.
Other market networks have of course network effects on the nodes, but a network of talent does not equal a network effect.
Challenge 8: Positive and negative network effects of talent funnels based on services
In a market network you often have multiple people (teams) involved in delivering a service. Very often those service suppliers are dependent on each other and follow a certain order.
At Hackerbay we wanted to test certain talent funnels and stages and see the impact of positive and negative network effects towards a certain task (like lower price, faster turnover).
There are multiple challenges with orchestrating multi-stage networks of people. We are currently running several private beta tests on orchestrating hierarchies with different management methodologies to see the impact of results. Stanford’s research in so-called flash organizations is a breakthrough on open-ended goals, but unfortunately there is no real decision, if an OKR based management system or an MBO based system is more effective in delivering positive network effects. We are experimenting currently with a mixed-model based on the tasks, which increases complexity, but can be maybe soon managed entirely by software.
Challenge 9: Transactional learning loops vs. non-transactional learning loops
Building software one of the most important things is to have a proper learning loop in place. In market networks, we noticed that it’s really important that your learning loop is close to the transaction.
We call it the transactional learning loop: Do you have feedback loops (like ratings) implemented after a transaction ($$$) or do you have feedback loops in general implemented after a certain timeline, like a milestone completed.
The challenge in software market networks is that it’s very hard to modularize software projects upfront and put certain transactions in place. We invented some transactional milestones, but this is of course changing again the industry standard and this impacts scalability of the market network in a negative way.
Challenge 10: Variance in service quality (geography, age, timezone)
At Hackerbay we noticed a challenge in the variance of service quality not based on the skill, but just different developer experiences.
For example a different age, geography could change the results of a given software project, not because of the talent of the developer, but because the priorization in the scope was just done different and not according to the standard of the client. As an additional complexity we noticed management complexities, because of timezones.
We analyzed and noticed that 500km radius between developer and client is at the moment leading to the best results in scope (expectation — reality = disappointment).
If you scale up market networks geographically, we suggest you manage supply & demand with a certain — industry specific — geographic radius.
Challenge 11: Complexity of key performance indicators (activity vs. output vs. outcome)
Another dimension of complexity is finding the right key performance indicators in market networks. It was really hard in 2005 to know that retention is the core metric for a social network; for market networks the really success KPIs are not yet defined and obvious.
We noticed that the character of an KPI for retention should be chosen wisely:
We discovered so far 3 different ways to look at the retention / repeat business metric of a software development market network:
- Activity
Not valuable for the overall service quality, but measurable. Let’s take workshops as a KPI. Workshops can be bad or good, but they are always complete, when the date is completed. Moreover workshops can be bad or good, but you as a platform is not measured by the outcome of the workshop per se, but because of the facilization of the workshop.
- Output
We started at Hackerbay with measuring finished projects. This was really hard to move to the network, because as a middleman you were not always capable of generating the output. E.g. the client did just decide that the project is out of scope and therefore not complete. As a consequence the challenge of scale is even more complicated, because you can’t directly influence all complexities.
- Outcome
Measuring your market network by the outcome is not the best idea. An outcome model would in software would be pay per active user. This metric is even less actionable on a network. Moreover fierce competition will drive down the prices. Performance indicators are of course the best for the end-user (user adoption), but they are also not good for the players in your market network (software developers, etc.).
In 2017 we decided to focus on output and a better customer experience, just like Uber did. There are a lot of low hanging fruits in the software industry, which can enable your company to get competitive advantages. Moreover it is easy to move to activity, when you already measured yourself at output (or outcome). It is really hard to go from activity to output.
But as a market network you should know what KPIs to focus on, and you should decide wisely, when you switch the KPIs and therefore gain advantages in the marketplace.
Challenge 12: Competition vs. community (service provider network dynamics)
There is a 2-sided platform network effect in marketplaces with a high volume (the more buyers, the more sellers, the more sellers, the more buyers). In less complex services like Uber the interchangeability of the service provider is leading to this 2-sided marketplace, because it doesn’t really matter, which driver picks you up, as long he has a certain rating.
This competitive element of drivers / service providers enables a market place to function and bring in efficiencies. In creative industries and professional services competition is existing as well, but it’s not as clear, who is good and who is bad, because of the service. As a consequence community and networks of trusted nodes become more important. Moreover software developers often work in teams and those team networks trust each other and work together (1+1 = >2).
As a market network it is really important to balance competition (efficiency) and community (trust). Because of the complexity, we at Hackerbay, are still invite-only on the service provider side (200 developers that we trust) and we are running competitive funnel experiments with details of a project, which we move to a competitive service provider cloud (e.g. CSS implementation) with certain milestones and up or out dynamics.
But those competitive elements are still in private beta and not in production. At the moment, we believe there will be a different levels of software developers and a new form of non-linear career paths.
Conclusion
Market networks are a fascinating vertical in software businesses and we are looking forward to spend the next 10 years of our career with bringing professional services online.
Hopefully this article can help other founders and the general market network industry to move ahead.
If you want to change the nature of software development, become the Henry Ford of software and drive the world towards the digital economy, join us! #GlobalizingHackerCulture
