16 March 2015

Empathetic Software Development Guided by the Business Model Canvas

A development team’s effectiveness is constrained by a lack of business awareness. Most developers are too technology focused, and most management teams drip-feed their developers partially-solutionized problems based on their poor technical knowledge and gut feelings.

Clearly, there is massive value in aligning teams with a shared organisational vision. We can do this using the Business Model Canvas to create empathy between business and technical colleagues; in the process creating efficient organisations that innovate from the ground-up.

Whether you are a leader by job title or by nature, I encourage you to bring the benefits of the Business Model Canvas to your company.

Business-focused Technical Teams are More Effective

It’s fun to be a developer. I, myself, love the act of writing code and building computer programs. I get a thrill from trying new technologies and learning new things. But most software developers I have worked with are overly-obsessed with this part of the job.

Passion is one characteristic of successful developers. Enjoying coding is, in my opinion, necessary to be good. But understanding how businesses work, how we can make customers happier, and how we can help the business to execute their vision as efficiently as possible leads to a whole new level of productivity. It’s the code you don’t write that can make you orders of magnitude more effective.

Too many non-technical people are forced to drip feed their developers requirements or write extensive documentation because developers constantly misinterpret them or build the wrong thing. This is because most developers do not understand their company’s business model or intent - they don’t understand the why.
"Software projects fail when you don’t understand the business domain you are working within well enough. Typing is not the bottleneck for delivering a product; coding is the easy part of development."

I believe that a number of great thinkers in the industry are already showing us that there are more effective ways of working. DevOps, Agile, BDD - behind all the marketing hype and misinterpretation - are actually about aligning people with the shared organisational vision to increase efficiency, autonomy, and innovation.

The Business Model Canvas can instigate or enhance a business-focused, innovative culture. I’ll try and persuade you more with a concrete example.

A Business Model Canvas Example

Below is an example of a Business Model Canvas illustrating the business model of an online travel agent. I’m going to explain how some of the information presented on the BMC can focus technical teams on what is really important to the business; making the team more effective.

An Online Travel Agent's Business Model

Value Propositions

What makes customers want to use your products or services? Can you save them time or money? Can you help them find a date? Maybe you can help them monetize their skills? These are a business’s value propositions.

As a developer, I want to know what the business I am working for’s value propositions are so that I can focus my time and efforts effectively. I want to know how a business creates value so I can make them better at doing it.

Looking at the example BMC, you can see the travel agent’s value propositions are about helping customers at the bottom-end of the market discover cheap deals. So maybe I will suggest technical improvements around recommendations or search. I won’t rack my brains on improving the payment system or the weekly reports because the business is unlikely to generate much (if any) extra revenue - no matter how technically brilliant my team’s solution is.

Whenever there is ambiguity in requirements or a scheduling conflict, I can look at the value propositions to understand the intent of the business and map out the best options.

Customer Segments

Who are the different types of people who buy your products? Bargain hunters? Chief Technology Officers? Marketers? Pet lovers? These are your customer segments.

As a developer, I want to know the customer segments my business is targeting so that I can help to really shape the products I am building around their needs. If they are tech savvy it might make sense to add power user features. If they are music lovers I should always be focused on building features that make it easy to connect with the tunes and personalities they are passionate about.

Sure, you can leave designing features to the product owners and business stakeholders. But I’ve seen many great product-focussed suggestions coming from developers who are engaged in the problem domain. Sometimes, the best ideas are only obvious to developers.

In my example BMC, we can see there is just one customer segment - the bargain hunters. People who just want a cheap holiday and good weather. As a developer, I can use this knowledge to make every feature the team builds focused on finding the best bargains, rather than a generic system that caters for all different price points.

But with this business model knowledge, me and my team can also be innovative. We can propose to the business ways of enhancing the product or building new products to attract different customer segments; especially with technically-based solutions that the business are unlikely to propose themselves.

Key Resources

What are the most important “things” that the business needs to provide the value propositions? Technical equipment, people and intellectual property are three examples that could be identified as key resources for some business models.

For the online travel agent in my BMC example, their key resources include exclusive low-price deals with hotels and their reputable brand. As a developer, I can use this information to focus my efforts - to make sure that searches are configured to prefer these exclusive deals or that the recommendations engine weights them favourably (after collaboration with the business).

If I, or my teammates, have any innovative ideas that maximise these key resources, I know that there is the potential to make a big business impact. That motivation of making a significant difference is the buzz I constantly chase. It’s very rewarding and invigorating.

Key Activities

A business may have many processes comprised of many steps. From paying monthly salaries to replenishing stock. But which are the ones that differentiate the company or play a fundamental role in fulfilling the value propositions? These are the key activities.

For my online travel agent friends, securing exclusive deals and marketing are some of their key activities. As a developer, I could use this information to help the company build a business-case, based on the technical strengths of our platform, that compel hotels to provide us exclusive offers.

Knowing that marketing is a key activity, the development team could focus their efforts on making sure any adverts are blazingly fast to appear. Or they could ensure that all of the metrics from emails and customer website behaviour are available in analysis and reporting tools.

The team can even suggest new technologies that make gaining insights from the actionable metrics easier. But that can only come from an understanding of the metrics’ relevance to the business.

Cost Structure and Revenue Streams

What are the most significant costs a business incurs? How many developers do you know that could answer that question? Suppose the most significant costs are bug fixes, support, or system maintenance. Developers can identify ways to cut these costs through technological or process enhancements - but only if they are aware of the costs.

Equally, technical people can put extra focus on the key revenue-generating parts of a system, by making it faster, more reliable or proposing new technologies to improve or revolutionise it.

And so much more….

I could have written an entire blog post on how each section of the canvas is useful to technical teams.

For example, I have been in a technical design meeting where we have gone round in circles debating the best solution to a set of requirements. The requirements were so vague that everyone interpreted them in a different way. This happens frequently in most organisations because business people are often not able to unambiguously express their intent.

"Understand the value of the product you are working on and what return on
investment (ROI) it brings to the company. Talk to your business sponsors about the future of the product to help focus your coding efforts; know what is important to them."

With a Business Model Canvas we would have had a better idea of the business’s intent despite the vague requirements. We would have then spent more time understanding the domain and proposing solutions or asking questions rather than arguing over futile data models.

Another example where the BMC shines is prioritisation. If you bluntly ask the business: “what are the must haves”, they’ll tell you almost everything is. But if you understand the business model, you can be far more intelligent with your questioning and reasoning.

For now I just wanted you to get a basic idea. There is far, far more potential than I have managed to convey here. The best way to find out is to give it a try. I’ll share some suggestions for how you can easily do that next.

Bringing the Business Model Canvas to your Organisation

Engineers, managers or just about anyone else can bring the Business Model Canvas to an organisation.

With the bottom-up approach, I recommend that a development team draws up what they think is their business’s business model. It doesn’t matter if you are wrong, just have a go. Then take it to the business.

The business may not know what a BMC is, so you’ll need to educate them. I find it best to start with the value propositions and customer segments, since they really are the most fundamental aspects.

What I found out with this approach is that when you show the BMC to a manager you will be wrong. But you’ll get some amazing insights. On one project I was involved in, our value proposition guess was wrong. The manager said, this application is fundamentally about making this process social. We thought buying and selling was the key aspect. That meeting drastically altered the way we went about building the product. We were all stunned by what a difference the BMC had made.

Top-down can also work. In fact, anyone non-technical working with software development teams can introduce a dev team to the BMC. Just show the developers that you want them to be more business-focused, and motivate them by showing they are here to solve hard problems and not just to crank out Jira tickets.

Even with the top-down approach, I’d recommend letting the developers draw up a BMC on their own. When the developers realise they didn’t actually know the business model, I think they’ll be more motivated to learn about it.

You can find a lot of great advice about becoming a more business-focused developer in Part 1 of the upcoming Patterns, Principles and Practices of Domain-Driven Design book. Factor my bias into your decision though because I was one of the book’s authors.

How Can You Get Started?

Should you be keen to learn more about the Business Model Canvas, Business Model Generation is the book to read. Then you should try and run workshops in your organisation.

If you have any specific questions or would like more information, you can also leave a comment or we can have a chat on skype. Just email me your skype ID. If you provide beer and pizza I could even come and speak at your user group or conference.

Finally, if you prefer some personal training to accelerate your learning, I may be able to run a workshop for you. It's best to send send me an email.