• innovation strategy sessions with the goal of figuring out what products or services to develop in the medium or long term.

• threat modeling workshops with the goal of identifying the crown jewels of a company and its customers to gather knowledge about where to focus security measures.

• technology assessments with the goal of aligning the technology strategy (including the key technologies and the people using those technologies) to the digital product strategy

• software development process assessments with the goal to build a better product more efficiently.

During all these activities, the same same “product” questions were asked to provide more context:

• What problem are you solving and who exactly are you solving it for?

• What key product features help the user solve this problem?

• What are the alternatives including competitors? Who are your competitors and what key features do they provide to solve the same problem?

• What are the benefits of your solution compared to the alternatives? What makes your solution better than the alternatives?

• What does the high-level solution look like?

• What are the key technologies used as part of the solution?

I thought, why not give it a try to also express my thoughts about the essence of product management, and the responsibilities and skills of a product manager?

At most companies or at least the ones I visited, product management is an underdeveloped capability. Many are talking about product management but few are actually (really) doing it. This is not a blame, product management is hard to get right since many people are involved in the product management process.

Although most of this article can also be applied to managing physical products, it’s focused on managing digital products.

I’ve also added an additional challenge for myself. I’ve decided not to use any additional fancy tools like ChatGPT (or other large language models). It’s not that I’m against this technology, I love to use it for inspiration and ideation. It’s been a while since I have published something and I want the article to feel imperfectly human. In an age of information overload and limited attention spans, I believe we don’t need additional AI-generated content. I’ve also time-boxed writing this article to two hours. I will view this article as an MVP that I will iterate upon once I gather more feedback and new insights.

What’s In A Name

Let’s start with a simple definition.

A product manager's responsibility is to bring the business closer to its goals by ideating, developing, and launching products and services that the market loves (and customers want to pay for).

Most often services like training, custom implementations & integrations, and support hours are linked to a digital product. These services might come for free with the product or they might be charged.

In smaller companies or start-ups, the CEO takes care of product management. When there is only 1 product and this is the main revenue generator, it’s very logical that the CEO takes up this role. The CEO is an expert in the problem domain and is the one that is doing the sales and decides how to position the product in the market.

A product manager at a company that’s offering multiple products, can be seen as a mini CEO responsible for the whole lifecycle and value chain of one or multiple products.

In technology companies where the domain of expertise is about technology, it’s very often the CTO that executes the product manager role.

Sometimes the one responsible for the product is called the innovation manager, the R&D manager, or the product owner.

In established or larger companies, the product manager is a leader without formal authority in the sense that he in most cases does not manage people. He only manages the product.

Establishing Strong Interfaces

While it’s the PM’s responsibility to create innovative solutions to market problems, he depends on a whole bunch of other people to create, develop, and launch successful products to the market. It’s important for the PM to establish strong interfaces with R&D, sales & marketing, the executive team, and customer service.

• R&D: The PM knows how to align the technology strategy with the product strategy. He’s aware of the relevant technology enablers and works closely together with the CTO. He provides the R&D team including designers and engineers with problems to solve. He does not provide them with solutions. He fosters collaboration and trusts them given their specialized skills to come up with the best solution to the given problem. The PM makes sure the solution is desirable and feasible. The PM manages these risks by first creating prototypes that can be tested by the market before going all in on a given solution. Managing risk is key to success.

• Sales & marketing: the PM makes sure that the benefits and the positioning of the product are crystal clear. He makes everyone aware of how the product differentiates itself in the market and how it is better (different) than the competition and the alternatives. The PM knows how to leverage marketing to verify assumptions about market needs by creating low-fidelity prototypes. The sales team is perfectly positioned to learn about the existing objections prospects have to buying the product. It’s important that this information reaches the PM.

• Executive Team: It’s not only enough to build products that are feasible and desirable. The product should also be viable and aligned with the business goals. Without a working business model, the business goals will never be achieved. Simply stated, in the long run, the total revenue should exceed the costs to build and operate the product.

• Customer Service: The PM knows that customer service is the best spot to gather valuable customer feedback and insights about how existing customers use the product, what they love about it, and also what frustrates them or poses problems. While it is very useful to look at the reported bugs in the ticketing system, it’s not enough. The PM knows he should create an interface with the customer service representatives to get more insights and hear qualitative feedback that aids the PM to start building hypotheses for product improvements.

Strategy, Alignment & Focus

Although a great PM possesses technical skills, it’s the PM’s soft skills that make the real difference. Using his soft skills, the PM excels at creating alignment and focus:

• Alignment: the PM launches and manages initiatives that do not fight but strengthen one another.

• Focus: the PM knows how to prioritize and focus on solving problems that have the most potential impact

Creating alignment and focus is the result of developing a strategy and communicating that strategy in an effective way.

Developing a strategy starts by diagnosing the problem to be solved. The strategy is crafted by gathering knowledge and insights about the company’s or team’s current strengths & weaknesses (people, processes, current products, and technologies), and the opportunities and threats in the external environment (market trends & needs, competitors, new technologies).

A product manager is a strategist. Crafting a strategy is a collaborative and cross-functional effort with the product manager as the key figure. It’s not an implementation. It provides a guideline to leverage opportunities and reduce threats. It should ease and facilitate lower-level decision-making and create alignment and focus.

The PM is great at communicating and making people collaborate. He’s an empathetic listener, and he is open-minded. He loves different points of view that help him to collaboratively build a solution with minimal complexity and maximum impact. He knows that a random team of individuals with different specializations is always better than one expensive consultant (that is even great at his job).

When the PM detects misalignment, he uses his communication and negotiating skills to resolve the conflict and steer the ship back in the right direction.

Automation Superpowers

AI and automation help out the PM during the job but his critical thinking skills can’t be replaced by a bot to solve complex problems.

The product manager knows that data is a critical component for building successful products. He knows that automation and AI are enablers for building better solutions and creating more efficient internal processes.

The PM knows that 360-degree company and product data can give him superpowers and that it will allow him to better support his decisions and convince team members about the chosen direction.

Automating the build process through continuous integration, deployment, and delivery help to confidently release software more frequently and create an experimentation culture.

Creating a (semi-automated) feedback loop using the 360-degree company and product data has the ability to further boost the experimentation culture and help to minimize market risk and maximize opportunities.

Conclusion

A product manager's responsibility is to bring the business closer to its goals by ideating, developing, and launching products to the market that customers love. He’s market-focused but he’s also aware when it’s favorable to leverage a specific technology to build a solution. He’s also a master at identifying and assessing risks.

He’s the key figure that enables a diverse team of people with specialized skills to work toward a common vision and solve a common problem. While he often has no formal authority, he is able to lead and motivate teams and individuals.

The PM is a strategist and excels at creating alignment and focus. The product manager is able to establish strong interfaces with R&D, sales & marketing, customer service, and the executive team.

He complements his critical thinking skills with data insights and automation. While he possesses a technical skill set, his soft skills make a bigger difference. He’s an empathetic listener and has great communication, collaboration, and negotiation skills. These skills enable him to navigate complex situations and always find a solution to a given problem.

Love to Hear Your Thoughts

I’m curious about how you think or feel about product management and the product manager role.

• What did resonate and what didn’t it?

• How does product management work at your organization?

• Who’s responsible for the product?

• What are the biggest challenges or obstacles when it comes to product management?

Subscribe now

🗞️ In This Edition

Ready for a mental workout? Buckle up, because this edition is packed with thought-provoking topics that have kept my brain buzzing for months! Let's dive into:

• The battle between corporations and our own well-being

• Discovering my purpose with the mysterious Ikigai Framework

• Navigating life and business with the help of North Star Metrics

• Uncovering the root cause of climate change and what we can do about it

• Technological advancements: a tool that cuts both ways, capable of fostering either positive or negative outcomes.

• The path to sustainability through a focus on well-being

If these subjects light your fire, then keep reading and join the journey!

It's been a while since I hit the publish button. I've been taking some time off during the holiday period to spend with friends and family. Last week, I also enjoyed some winter sun with my family in Malaga.

During my time away, I took the opportunity to step back and examine the bigger picture. I reflected on what is most important to me and tried to discover my purpose. Without a clear mission and vision, it is impossible to develop a personal strategy and set goals that will lead to fulfillment and bring more focus to life. Doing this also helps with eliminating distractions and becoming more productive as I work towards my long-term goals.

During my quest for personal fulfillment, I discovered significant disparities between human behavior, economic development, technological advancements, and overall well-being.

Profit vs. Well-Being

Most companies often chase the almighty dollar, ignoring the long-term well-being of both people and our planet.

Sure, their products might give us a temporary high, but they also have the sneaky tendency to bring us down.

And don't even get us started on the climate change problem! We're just not feeling the urgency yet... but that doesn't mean we shouldn't be!

By taking the time to understand what brings us genuine happiness and fulfillment, we can reduce our carbon footprint while enhancing our well-being. No more relying on products with sneaky negative side effects.

I wrote this article because I wanted to find more meaning in life. I'll show you how you can do the same.

The Ikigai Framework

The Ikigai framework is represented by a Venn diagram with four overlapping circles: what you love, what you are good at, what the world needs, and what you can be paid for.

The intersection of these four circles represents your Ikigai, or your purpose in life. The following sketch shows my personal result. It’s a fun activity, you should try it for yourselves.

I’ve set some new and exciting personal leisure goals that align with what I love and bring me energy. These include both travel plans and sports challenges.

In a couple of weeks, I'll be hiking the GR 131 with three of my closest friends in Tenerife. In April, I'll be going on a three-week journey with my girlfriend to the eco-friendly and biodiverse country of Costa Rica. We’re both nature lovers so it's going to be a paradise for us.

Additionally, I'll be running the half marathon in Ghent at the end of March. It's good to have goals to work towards.

I also love creating a positive impact. The discussions I had last year with business leaders have proven that the gap between business leaders and technology teams is real and rather large. My product management and technology skills help to bridge this gap and make a positive impact.

BUT product management and technology are powerful tools that can be harnessed for either good or bad to achieve what's truly important to me and to this world.

North Star Metric

A North Star Metric is the single metric that best captures the core value that your product or service delivers to customers.

A North Star Metric is a well-known concept in the field of product management. Most of them are tied to maximizing profit.

Some examples are increasing revenue, customer growth, and consumption growth.

Your North Star is your strategy and your strategy is your North Star.

I believe prioritizing profit conflicts with creating a sustainable future and our personal well-being.

Navigating a Path to a Sustainable Future

In my previous article, I have been writing about how to prioritize what to build next for your product. The approach I discussed there enable companies to avoid wasting money, time, and talent. It also helps you to innovate more quickly that the competition. The systematic approach I provided focused on prioritizing what to build next based on customer value.

I also talked about solving big problems. I have defined it as follows:

A big problem is either:

• a problem many people have

• a very painful problem for a few people

• something in-between the previous two

Climate Change

Climate change is the most pressing long-term issue facing humanity. If we want to ensure the well-being and survival of future generations, it is crucial that we prioritize the protection of the environment and reduce our impact on the natural world.

While our planet will ultimately survive and find a new equilibrium, it will be at the expense of human civilization.

It is imperative that we take immediate and decisive action to address this crisis before it's too late.

But most of us perceive it as an important problem that is personally not that urgent. However, it is an urgent and important problem for humanity.

Root Cause: Consumerism

The root cause of the climate change problem is consumerism and overconsumption.

I recommend this great article from Greenpeace. It explains why the circular economy alone is not going to save us all. We also need to slow the circular economy.

Innovative automation (like AI) technologies might enable companies to make industrial processes more efficient and sustainable. But even in a circular economy: if companies keep focussing on profit and growth, this will result in increasing the carbon footprint even more. We need to stop cycling more and more resources around faster and faster.

It’s necessary to:

• slow the circular flow of using resources: re-use, repair, re-gift, recover, and recycle

• close the loop by reducing production and consumption: refuse and reduce

The Battle Between Corporations & Our Well-Being

Our constant pursuit of fulfilling our needs and desires is leading to the rapid and unsustainable depletion of the planet's natural resources. Additionally, our current economic system, which prioritizes endless growth, is exacerbating this damage to the environment.

Most companies are for-profit companies. They create value for consumers and make a profit by doing so. A high return on investment is most often the main goal for their investors and shareholders. There are also nonprofit organizations. Their purpose is to create value for the community with no intention of earning a profit.

The idea of working for a non-profit organization or even founding one is certainly appealing, but I also believe that those who work to better the lives of others or the planet should be adequately compensated for their efforts. While monetary compensation is not the only form of recognition, it does provide the means to fulfill other needs and desires.

It is important to find a balance between rewarding good deeds and not becoming overly focused on financial gain.

It is one thing to believe in the cause of combating climate change, but making big personal sacrifices to do so can make the decision challenging.

Consumerism ≠ Well-Being

Our society's emphasis on consumerism encourages individuals to acquire an excessive amount of goods and services. The economy is driven by the constant buying and selling of products, leading to a focus on materialism and the acquisition of possessions. However, this often results in waste and harm to the environment. Many things that we buy, might bring us temporary pleasure, but it doesn’t bring us long-term happiness.

The Hedonic Treadmill

Research has shown that the acquisition of material possessions does not lead to long-term happiness. The hedonic treadmill theory suggests that as individuals acquire more wealth, their expectations and desires for material possessions also increase, resulting in a lack of permanent gain in happiness.

Happiness changes with good and bad events but goes back to normal quickly. People who win the lottery go back to being just as happy as before, and people with serious injuries like paraplegia and quadriplegia adjust and become just as happy as they were before. Only events from the last 2-3 months really affect our happiness. There are a couple of events that do affect our long-term happiness like widowhood and long-term employment.

The PERMA Model

Martin Seligman, the father of positive psychology, introduced a comprehensive model for well-being that goes beyond just chasing pleasure and material wealth (=hedonism).

The PERMA model encompasses all the key factors that contribute to true happiness, including Positive emotion, Engagement, Relationships, Meaning, and Accomplishment. This holistic approach provides a more fulfilling and satisfying path towards well-being, compared to the narrow focus of hedonism.

The different components of well-being according to the PERMA model:

• Positive emotion (=Hedonism): This refers to experiencing positive emotions and feeling good.

• Engagement: This refers to being fully absorbed and involved in an activity that you find meaningful.

• Relationships: This refers to having strong and supportive relationships with others.

• Meaning: This refers to having a sense of purpose and meaning in life, through activities or causes that are important to you.

• Accomplishment: This refers to experiencing a sense of achievement and accomplishment through reaching personal goals.

Technology ≠ Well-Being

Technology's impact on individuals' well-being can be both positive and negative.

The companies building digital technologies most often do not prioritize well-being. They prioritize profits for their shareholders.

Let’s revisit some of the North Star metrics I’ve shared before:

• The strategy of social media companies like Twitter, Facebook, and Instagram measures success based on the number of daily active users.

• Netflix measures success by the median view hours per month.

Companies like Facebook, Twitter, Instagram, and Netflix use AI to keep us engaged with their platform. They make it tempting so we'll spend more time there and they can make more money.

Feeling good from social media likes and comments may provide a quick thrill, but over time, it can actually harm our overall happiness. Watching too much TV takes away from pursuing goals that really matter.

But these companies and the AI algorithms don't care about our happiness, it just wants us to spend more time on their platform.

Be aware however that while these platforms offer valuable benefits, they do not prioritize your well-being.

Disruptive innovations like television, social media, and AI are prime examples of how technology can lead to positive and negative outcomes for our well-being. These advancements have brought about many benefits, but also raise the question of whether they have truly led to an improvement in the quality of life.

Double-Edged Sword Examples

It’s up to the consumer to use technology in such a way that it promotes personal development, rather than causing the loss of skills, motivation, or results in negative behaviors or habits. However, this task is not as straightforward as it may seem.

Television

😊 Television can be a source of entertainment and information, providing access to news, education, and a variety of programs that can be enjoyed by people of all ages.

😒 Excessive television viewing can lead to a sedentary lifestyle, which can contribute to obesity, heart disease, and other health problems. Additionally, some studies suggest that excessive television viewing can contribute to poor academic performance, sleep disorders, and attention problems.

Social Media

😊 Social media can help people stay connected with friends and family, and it can also be a powerful tool for social and political change. Additionally, social media can help people find and join communities of like-minded individuals and can be a great way to share information, ideas, and experiences.

😒 Social media can also be a source of stress, anxiety, and depression. It can also be a breeding ground for misinformation, cyberbullying, and hate speech. Additionally, social media can be addictive, and excessive use can lead to problems with sleep, attention, and impulse control.

AI

😊 AI can help improve efficiency and productivity in a wide range of industries, including healthcare, finance, and transportation. Additionally, AI can help to improve decision-making and automate repetitive tasks, freeing up time and resources for more important tasks.

😒 AI can also raise ethical concerns about the loss of jobs, the lack of transparency in decision-making, and the potential for data misuse. Additionally, there are concerns about the impact of AI on privacy, security, and the potential for AI to perpetuate existing biases and discrimination.

The Power Of Mindful Consumption

Ready to live life to the fullest while saving the planet? It's time to prioritize well-being over profit.

Let's shift our focus from consuming more to creating a sustainable future.

We have the power to make a difference as consumers by choosing products and services that align with our values, goals, and our well-being.

By using technology mindfully, we can also reap its benefits while avoiding its negative consequences.

Balancing profitability with well-being and social responsibility is an opportunity for companies to create positive change.

The future is bright and full of possibilities for a sustainable, happy life!

🎤 Join the conversation

Share your thoughts! Leave a comment below on how you prioritize well-being over profit in your daily life and what opportunities you see for companies to do the same.

Leave a comment

📚 Recommended Books

Here are some recommended books that inspired this article:

• Positive Psychology in a Nutshell: The Science of Happiness by Ilona Boniwell

• Authentic Happiness: Using the New Positive Psychology to Realize Your Potential for Lasting Fulfillment by Martin Seligman

• How to Avoid a Climate Disaster: The Solutions We Have and the Breakthroughs We Need by Bill Gates

Hi there, it’s Niels. 🤗 Welcome to my newsletter. This newsletter helps with the creation of valuable software solutions, making better software investments, and improving the developer experience. Questions? Ask them here.

Subscribe now

In April this year, I joined Sirris. Sirris is a not-for-profit organization that helps Belgian companies to achieve their innovation ambitions. This includes building innovations and helping them to adopt new innovations.

After 6 months, I’m starting to see patterns of what businesses struggle with. In this edition, I’m going to talk about one of the hot recurring topics that we help our customers with that are relatively new to building digital products.

What kind of businesses am I talking about exactly?

• Businesses that are shifting from building digital solutions to digital products.

• Businesses that are enhancing their physical product offering with digital product features.

Many of these businesses have trouble deciding what to build next and how to put together their product roadmap. This includes finding out which initiatives make sense to proceed with and how to prioritize the remaining ones.

They realize that poor decisions will lead to a waste of their resources including money, time, and talent. That’s also the time that they come to us for help.

At all times, you should avoid building products and features that no one wants (bad enough so that they want to pay for it).

What are the consequences for your resources when you do build products/features that no one cares about:

• money: If no one wants to pay for your solution, your business will lose future revenue, and your investment to build it will be a sunk cost.

• time: Your competition moves forward while your own business is moving backward. Your product becomes more cluttered with features no one wants.

• talent: Your expensive software engineers are spending their talent building solutions that are not used. This will eventually lead to unhappy and unproductive employees. You even risk losing your engineers to other companies.

Keep on reading for an actionable step-by-step plan to prevent all these bad consequences from happening!

It will also help you to increase revenue, avoid sunk costs, and innovate more quickly with a happy and productive team of software engineers.

I want to stress that this article focuses on what to build next to increase customer value.

There are also other things to consider when developing products but these are not in scope for the remainder of this article: e.g. technical debt, internal process improvements, security issues, and legal issues.

Step-By-Step Plan

Your goal should be to minimize the RISK of building something that no one wants bad enough. The risk is twofold:

• There is a risk that your business solves the wrong problem.

• Even when your business finds the right problem to solve, you might still invest huge resources in building the wrong solution.

It’s important to derisk both of them and increase your chance of successful investments.

Find The Right Problems

Explore Problems

You should first have insight into what problems should be solved and for who exactly. The best way to find out is through interviews. These interviews will return qualitative data about what matters to the interviewees.

Interviews

These interviews should answer the following questions:

• Who are they?

  • Who are these different types of people exactly?

  • What identifies them, how do I recognize them, and what makes them different from other types of people?

• What do these people do?

  • What jobs do they need to do? What problems do they have while doing it?

  • What jobs are most important to them, and what are their biggest struggles?

  • How are they doing their job now and what are the alternatives that they are using?

One of the biggest mistakes that you can make is to assume you know who the (potential) customers exactly are and what problems you should solve for them.

Markets

It’s important to define what a core market and an adjacent market are. This will help to better explain what kind of people you should interview.

• A core market is defined as a group of people (the job executors or personas) plus the job they want to get done using your product.

• An adjacent market is a market that includes either the current job executor or the current job that people want to get done, from the perspective of the company.

What people should you interview exactly and why?

• Existing customers

  • Core market: discover the pain points with the existing product and features

  • Adjacent market: to gather information about related problems they face that aren’t covered by the product yet

• Potential customers

  • Core market: to discover what they like/dislike about the alternatives to what your product is offering

  • Adjacent market: to discover what’s missing to apply your existing product to another type of job executor

Prioritize Problems

If enough interviews happen, results should start to converge. If the results don’t converge, it might help to tune your customer interview and ask better or other questions.

It helps to create a screener for each type of customer. This is a question whose job is specifically to determine whether or not a given subject maps to a customer.

For each type of job executor, you should be able to gather the information depicted in the diagram underneath.

A persona is a synonym for job executor.

For the different types of job executors, you should be able to see:

• job importance: what jobs matter the most to them and what do they care less about

• job specific problems: a list of problems associated with executing that job

• problem importance: how painful that problem is

Solving big problems creates a lot of value for customers and the business.

What do I mean by a big problem? A big problem is either:

• a problem many job executors have

• a very painful problem for a few job executors

• something in-between the previous two

For the problems that do really exist, divide them into buckets based on their value. Try to keep it as simple as possible. I suggest using two different categories: High and Low

• High-value:

  • rank the high-value ones in descending order of value 👍

  • continue with the next step 👍

• Low-value: deprioritize, revisit later or remove altogether 👎

Find The Right Solutions

From now on, it’s important to include the team that will be responsible for implementing the solution. This includes your designers and software engineers.

Ideate Solutions

The product manager (or the person that is responsible for the product) can take the first stab at ideating a solution. Multiple solutions exist to solve the same problem. The goal is to select the best one. Other team members might come up with better ideas to solve this problem.

The goal is to come up with a solution that job executors prefer over what they are using now.

• For existing customers, your solution should be an improvement compared to how they use your product now to get their job done.

• Prospective customers from your core or adjacent market should be prepared to switch from what they are using now to your alternative.

You can’t simply ask a customer or prospect whether they’d like the product or feature you’re thinking of building. They’ll always say “yes”.

It’s the product manager’s job to select the best candidate solution to proceed.

Estimate Complexity

The technical team should be able to estimate the implementation complexity for the solution. This includes the time it takes to implement, the technical challenge, and the development cost. Try to keep this process as simple and quick as possible. I suggest using T-shirt sizes: e.g. XL, L, M, S

The product manager can then map these to high or low complexity and make better priority decisions.

Prioritize Solutions

A value-complexity matrix is a great tool that helps you how to proceed with high-value problems. Remember that we already deprioritized low-value problems before.

• high value, low complexity: easy win 👍

• high value, high complexity: If possible, break these down into less complex tasks. 👍

Important here is that you should not always select easy wins at the expense of high-complexity solutions. You need to invest time in both. High-complexity items might be more innovative and return higher value in the long run.

Derisk Solutions

High-complexity solutions should be derisked as much as possible. How to derisk them is dependent on the type of solution.

New Product

When moving into adjacent markets, it might make sense to create a new product while leveraging functionality that you already have in place.

This is the scenario where minimum viable products (MVPs) make sense. Most people think about the single-feature MVP when they hear the word MVP. But there are also other types of MVPs that might make sense for your specific scenario.

Using a low-fidelity MVP (which requires very minimal development) enables you to double-check the demand for your solution on a bigger scale than during the interviews.

The next step that you can take when the results are positive is to develop a high-fidelity MVP (which requires more development). This will show you how much customers are ready to pay for your product. It will also provide you with feedback about how to optimize your current solution.

Existing Product & Existing Job

Here it is important to verify if your solution is effectively an enhancement compared to the previous version. Rolling out this new version to all your customers at once would be a risky move.

Instead, you can roll out beta releases to only a small group of early adopters. This will result in useful feedback and it will make sure there are no major issues before releasing it to the general public.

Existing Product & New Job

This is a good moment to gauge if this product enhancement can be turned into a premium feature and how much they are prepared to pay for it.

Here we are somewhat in the middle of the previous two. If the complexity is high enough, both low-fidelity and high-fidelity MVPs might be of help. Rolling out beta releases to early adopters also makes sense.

Conclusion

Poor decisions about what to build next for your digital product will lead to nasty consequences for your business. My hope is by now, you have gained a better idea about deciding what to build next for your digital product to increase customer value.

I’ve explained how to find the most painful customer problems and prioritize what problems to solve first. It’s also important to take into account the complexity of a solution. For the best solution and the best outcome, great collaboration between team members is needed. Depending on the solution scenarios, MVPs or beta releases can help to derisk the outcome of a solution.

The next move is up to you! Do you want to increase your bottom line, innovate more quickly and forge a productive team of software engineers?

Don’t hesitate and contact me for tailored help that will boost your business!

I Need Help

📚 Read More

• The Customer Discovery Handbook

• Growth Strategy Inspiration: How to Grow Into Adjacent Markets

• Use a product value matrix to prioritize your roadmap

• Qualitative vs Quantitative Data

• Hypothesis-driven Development (Practitioner’s Guide)

• 9 Minimum Viable Product Types for Your Startup

Subscribe now

It’s important to deeply understand the problem before codifying a solution. A software developer first needs to build a mental model of the problem domain before capturing the insights in a programming language.

In my previous article, I talked about “The Hexagonal Architecture”. The hexagonal architecture dictates that there should be a clear separation between a software solution's inner application layer and the surrounding infrastructure layer.

• The application layer:

  • is described by functional requirements

  • subject matter experts (SMEs) hold the required knowledge of the problem domain (= core domain)

• The infrastructure layer:

  • is described by non-functional requirements

  • software engineers (SE) hold the required knowledge of the technology domains

There is a gap between these two layers that must be bridged to deliver cost-effective and valuable software solutions in time. Excellent collaboration and communication are needed between subject matter experts and software engineers.

Mental Maps

For codifying the integration layer, software engineers do not need any help from subject matter experts to create a second-degree map of reality.

• first degree: the mental map of the domain (technology domain)

• second degree: code as a map of that mental map.

When software engineers need to codify the problem domain, they depend on the input of subject matter experts which makes things considerably harder. Now, there is a need for a third-degree map:

• first degree: the mental map of the problem domain by subject matter experts

• second degree: translation of that mental map so that software engineers understand it

• third degree: code as a map of the software engineer’s mental map (based on the mental map of the subject matter experts)

Translation of the problem domain between subject matter experts and software engineers is very challenging. Information gets lost often. It also takes time, serious effort and interest for a software engineer to gain deep understanding of the problem domain.

Different approaches have been introduced to improve this mental mapping process:

• Use cases: textual formalization of the functional requirements to align SMEs and SEs

• Domain-driven design: increasing the understanding of the problem domain by SEs and creating a common language for both SMEs and SEs

• No-code & low-code platforms: reducing the need for mental mapping of the problem domain by SEs

These are great approaches and initiatives but there is still room for improvement.

Use Cases

Use cases are often replaced by user stories although they serve a completely different purpose:

• User stories are about the needs and benefits of the end-user and grew their popularity with the rise of Agile. These are expressed in one single sentence using the format: As a [type of user], I want to [need], so that I [benefit].

• Use cases on the other hand contain all the answers (about functional requirements) developers might have while codifying the solution.

They are both useful and can both be used in parallel.

A use case describes how an actor interacts with a system to achieve a goal. That goal is equal to the need for a user story. A use case contains:

• a goal: equals the need in a user story

• an actor: human or external system

• preconditions: the state the system has to be in for the use case to occur

• default path: the regular series of steps the system will take

• alternative paths (optional): conditions will lead to branching

• postconditions: actions the system takes at the end of the use case or the various states the system could be in after the use case concludes

Even when low-code or no-code is used and there are very limited dependencies on software engineers, this formalized textual description has tremendous value. It helps to think the use case through before jumping to coding the solution.

Domain-Driven Design

Every solution starts with insight into the problem domain. Subject matter experts own the knowledge and expertise about that problem domain.

A lot of domain information gets lost between subject matter experts and the software engineers that translate the domain into code. Many books have been written trying to solve the difficulties of this translation. Domains can get pretty complex to reason about and they often need changes. When something changes in the domain, the code should also reflect that which needs a change. It takes time for software engineers to deeply understand the domain.

Domain-driven design (DDD) is a well-known software design approach. It focuses on modeling software to match the domain based on input from subject matter experts. The idea is that the structure and language of software code should match the business domain. That way, a ubiquitous language is created that is understood by both software engineers and subject matter experts. It introduces concepts like aggregate roots, entities, value objects, and repositories. These concepts might be known to software engineers that have read about and studied DDD. But on the other hand, these concepts do not ring any bell for subject matter experts.

I’ve read the following popular books about domain-driven design in the past:

• Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans

• Implementing Domain-Driven Design by Vaughn Vernon

Technology is not hard for software engineers, understanding the problem domain is.

I’ve enjoyed reading them, and I’ve tried to apply them as much as possible in past projects where it made sense. Still, domain-driven design is hard. What makes it hard is the road to understanding the domain and then making sure the code reflects that domain.

Low-Code & No-Code Platforms

Low-code and no-code platforms try to limit the technology skills needed to build, test and deploy a solution.

• No-code platforms don’t require any coding skills. They allow configuring, composing, and interconnecting pre-built components.

• Low-code platforms also allow certain extensions of existing components or allow you to build new components. For that, coding is necessary.

Most platforms are a blend of no-code and low-code. Because without any code, you run into limitations very quickly.

While you don’t need much coding skills, be aware that you still have to learn how to work with the platform. Typically, the more flexibility is offered, the steeper the learning curve.

My opinion is that:

• No-code platforms can be useful for subject matter experts but these platforms have serious limitations regarding what you can do. The best no-code platforms solve very specific problems for a very specific industry.

• Low-code platforms are not a good fit for subject matter experts but can be useful for software engineers to speed up their work.

Here is why I think subject matter experts should stay away from the infrastructure layer:

Subject matter experts (unless their domain is software engineering) will never be able to create reliable integrations when the non-functional requirements are beyond basic.

Selecting the best database or choosing between asynchronous communication over a message bus or using a synchronous REST-API requires high software expertise. Even when using no-code drag-and-dropping, subject matter experts have no clue about the performance implications of attaching an integration (e.g. database query, REST-API call) to a business workflow or a graphical user interface element action (e.g. button click, form-submit).

Conclusion

Software engineers and subject matter experts should collaborate closely to create software solutions. Everything starts with a deep understanding of the problem domain.

• Subject matter experts hold domain expertise and lack technology expertise.

• Software engineers hold technology expertise and lack domain expertise.

Technology expertise includes writing and testing code but also integrations with external systems while satisfying non-functional requirements.

Uses cases are a great way to textually formalize the goals of actors, how to get there and what might go wrong. They contain all the answers to questions about the functional requirements developers might have while creating the solution.

Domain-driven design showcases how difficult it is to create a shared understanding of the problem domain between SEs and SMEs and make the code reflect this.

Low-code & no-code platforms can be useful but it’s dangerous to let SMEs control when and how integrations to other systems are called.

In an ideal world:

• Subject matter experts can model the domain including data and behavior themselves.

• Software engineers take care of the integrations so that the non-functional requirements can be satisfied

To facilitate this, transparency is needed for both subject matter experts and software engineers about:

• the high-level functional and non-functional requirements

• overview of the actors and external systems that will interact with the solution that is in scope

• definition of all the interfaces between the application layer and the infrastructure layer

🤔 What Else Is On My Mind?

I have been thinking if it would make sense to create a programming language aimed at subject matter experts that would enable them to model the domain themselves.

The article above was part of this thinking exercise.

The language characteristics that would help in my opinion:

• Turing completeness, so it should not be a domain-specific language (DSL). It should be applicable to model any specific problem domain.

• Statically typed to be able to better guide and protect subject matter experts. It would also allow auto-completion while developing.

• Simple: no 10 ways to accomplish the same thing

• Clear separation between data and behavior. I will motivate this one in depth in a future article.

  • data components:

    • which are mutable

    • they can have multiple instances

    • adding behavior to data elements will not be possible

  • behavior components:

    • no inheritance, the assumption is that domain experts have trouble understanding this

    • composition of dependent behavior components will be possible via the constructor

    • all behavior components will be singletons

    • data can only be used inside behavior as a function parameter, not in the constructor

This is just a snapshot of my thinking at this moment. I’m looking forward to your thoughts about this!

Leave a comment

📚 Read More

• Use Cases vs. User Stories: How They Differ and When to Use Them

• Business vs. Functional vs. Technical Requirements

• Domain Driven Design in 10 minutes - Part one

• Domain Driven Design in 10 minutes - Part two

• Rethinking Visual Programming with Go

This edition should help you to evaluate the technology components needed to put together a technology stack for one or more applications. I will cover:

• Technology evolutions

• Non-functional requirements

• Application architecture patterns

• Libraries, frameworks, cloud APIs, and low-code platforms

Subscribe now

Seven to eight years ago, I was part of a team with the task to investigate how our company could replace or evolve the current technology stack for building internal and customer-facing web applications.

In that current technology stack:

• Most of the data were stored in a relational on-premise Oracle database.

• Most business logic was written in PL/SQL. PL/SQL is a procedural language that’s available in an Oracle database.

• Oracle Forms was used as the front-end for internal applications.

• Customer-facing applications were built using diverse Java web frameworks which evolved through time. There were applications that used diverse and early versions of Apache Struts. Later on, the Spring MVC framework was also introduced.

• Some customer-facing applications required more browser-based interactivity. To support that we also built single-page applications using Angular.

The web layer was only a thin layer and called database (PL/SQL) procedures for executing business logic.

That architecture was suboptimal but like every architecture, this was something that evolved over time. Most of the applications were internal applications to support the business. The need for customer-facing applications to improve the service for customers grew over time.

It was hard to unit-test database procedures. It was also a pain to release new versions of web applications to production.

The idea from management was to investigate if we could replace the business logic layer (PL/SQL) and the presentation layer for internal applications gradually by using Java technology (since this was probably more future-proof).

The web team that I was part of was heavily involved in the change initiative since we were already using Java technology. There was limited involvement of the people working on the database and business layer. The web team was a minority and we were overall young, inexperienced, and lacked mentorship. A consultant was brought in with the goal to support us. We were advised to use Vaadin for the front end and Enterprise Java Beans for the business layer.

Long story short, we were part of “an internal battle” we could not win since:

• We were a minority and there was resistance to change from the other stakeholders.

• The proposed solution by the consultant was in retrospect, not the best solution.

• We struggled due to inexperience, and support and the change project died silently.

Looking back, I learned a great deal from a “failed” change initiative like this one. It also helps to look back at how the technology landscape evolved since then.

Technology Evolution

A lot of things have changed since then regarding technologies:

• The web frameworks (or their versions) from that period are seriously outdated.

• Many architectures are moving partially or completely to the cloud offering almost unlimited scalability.

• Increase and improvement of (cloud-based) tooling to support the development lifecycle e.g. monitoring, logging, CI/CD, …

• Low-code (cloud-based) platforms are also rising to create web applications.

• We were not aware of the existence of Docker. Docker back then was still in its infancy. Now it is the de facto standard for packaging and deploying applications.

• Most of our applications were (modular) monoliths. There was a lot of fuzz about microservices but we knew if we would go that way, complexity would shift towards the management of the microservices.

Other aspects have not changed that much:

• HTML5, CSS3, and Vanilla JavaScript are still here. These only evolved a little bit and still serve as the front gate of any web application.

• Java is still a very popular language especially for writing enterprise back-end code. The language evolved but stayed backward-compatible. More functional language features were added over time. Other languages like PHP, C#, and Python which were popular back then are still widely used.

• The three-tier architecture and the hexagonal architecture are both still very relevant.

Non-Functional Requirements

Every solution should be built based on requirements. Three types of requirements come to mind:

• Business requirements: these motivate WHY the business should do something. This is about nailing down what the problem is.

• Functional requirements: define the expected behavior of a solution or WHAT should be done to solve the problem defined as a business requirement.

• Non-functional requirements: they define the constraints on HOW that solution should be built.

When evaluating a future technology stack, non-functional requirements are key. For every application that should be built, these requirements will be different.

There is no 1-size best-fit technology stack for all applications

Some examples of non-functional requirements:

• Operationality: e.g. the chosen technology must be already operated by the team

• Testability: e.g. automated testing of business logic

• Financial viability: e.g. the total cost of ownership per year

Application Architecture Patterns

Three-Tier Architecture

The three-tier architecture is still relevant today for organizing applications. The three-tier architecture separates applications into three logical tiers. These tiers can also be physically divided and enable different teams to work on the different layers. A tier can also be subdivided into different logical and physical components.
These different tiers are layered on top of each other:

• presentation tier:

  • the top level of the architecture

  • the driving integration e.g. command line interface or a web application

  • Example: For web applications, this would mean serving HTML5, CSS3, and JavaScript (ES6) so the browser can interpret this and the end-user can interact with the browser.

• application tier:

  • the middle tier contains the business logic

  • the bridge between the driving presentation tier and the driven data tier

• data tier:

  • The bottom level of the architecture

  • The driven integration

  • contains the data-access layer that manages access to data storage like a relational database.

Hexagonal Architecture

Alistair Cockburn proposed the hexagonal architecture in 2005. It’s definitely not new and remains very relevant and useful.

The hexagonal architecture can be viewed as a flexible extension of the three-tier architecture. The application layer containing business logic remains at the heart of the architecture.

All integrations including databases and user interfaces are part of the infrastructure layer. It supports integrations with multiple driving actors and multiple driven actors.

• Driving actors: the ones that initiate the interaction like different user interfaces

• Driven actors: the ones that are put into motion by the application e.g. a database or a REST API. Both can be used to fetch or store data.

The integrations between the actors and the application layer occurs via ports and adapters.

• Driving integrations:

  • driving adapters will use a port

  • an application service will implement the interface defined by the port

  • both the port’s interface and implementation are inside the hexagon

• Driven integrations:

  • driven adapters will implement the port

  • an application service will use it

  • the port is inside the hexagon, but the implementation is in the adapter outside of the hexagon

Reusable Functionality

Libraries, frameworks, cloud APIs, and low code platforms are all pieces of reusable functionality written by an external party. Their purpose is to help solve common problems in easier ways.

It’s crucial to look at the non-functional requirements when evaluating these reusable components. Their choices have consequences.

Libraries & Frameworks

The technical difference between a framework and a library lies in the inversion of control.

A framework tells the developer what it needs. The framework is in control.

With a library, the programmer is in control. The programmer calls the library where and when they need it.

It is difficult to replace frameworks. A library is easy to be replaced with another library.

I personally favor lightweight frameworks (e.g. Express) with a limited amount of responsibilities. This makes them easier to replace compared to a framework that is used for everything (This is how using Spring feels).

Libraries and frameworks have to be compatible with the runtime of your project. A runtime is a platform for executing instructions. Popular example runtimes are the JRE (Java Runtime Environment) and Node.js (a JavaScript runtime environment). Runtimes do not enforce any development patterns. They only run the code.

I’ve mixed Groovy, Java, and Kotlin code in the same code base in a past project (I’m not saying you should do that). These three languages can all run in the Java Runtime Environment.

Because of the inversion of control, frameworks are tougher to debug.

I remember times that I spent more time debugging Spring code than my own code that I plugged into the framework.

I prefer to be in control. This improves the understandability of the code. This doesn’t mean I’m against using frameworks. I do favor lightweight frameworks with a limited amount of responsibilities. This makes them easier to replace compared to a framework that is used for everything.

More heavy-weight frameworks also have a steeper learning curve. If you don’t get the framework, you won’t get the codebase.

Framework examples: Spring (Java), Express (Node), Django (Python), Laravel (PHP), Vue.js (JavaScript), Angular (JavaScript)

Library examples: React (JavaScript), Reef (JavaScript), JUnit (Java), Mustache.js (JavaScript)

Cloud APIs & Low-Code Platforms

Contrary to libraries and frameworks, cloud APIs & low-code platforms don’t run in the same runtime. These are external components running in the cloud.

Cloud APIs are similar to libraries and low-code platforms are related to frameworks. With cloud APIs, the developer is in control. Using low-code platforms, the platform is in control and the developer fills in the missing blanks.

Cloud APIs & low-code platforms both offer scalability and security advantages ( they should).

Libraries offer an API to developers so that functionality can be reused. Cloud APIs also offer an API to the developer. Instead of calling the API directly in code, the API should be accessed:

• via a network protocol like HTTP(S) and MQTT(S).

• and using a message protocol like JSON or XML

A cloud API can be wrapped into a library where the library contains the abstraction for :

• connecting to the API

• transforming the request and response to data structures that can be understood by the runtime.

The goal of low-code platforms is to enable developers to create technology solutions faster and cheaper and with a limited need for technology skills for building, testing, and deploying functionality.

Low-code platforms dictate the flexibility you have over the end solution. The more flexibility you have, the steeper the learning curve. While you don’t need skills like writing code (including tests) and setting up CI/CD pipelines, be aware that you will need to invest considerable time to learn the platform.

It’s very difficult, often impossible to replace a low-code platform as part of the technology solution. The more responsibilities a platform has as part of the total solution, the more difficult it will be to replace it.

Debugging and testing are also often pain points in low code platforms. Testing expected behavior is most often a manual task. Most often these also don’t offer a way to mock calls to integrations like a database.

Cloud API examples: SendGrid Email API, Twillio Communication APIs, InfluxDB Cloud API for storing and retrieving time series data.

Low-Code Platform examples: Bubble for building web applications, Waylay for automating data workflows, Canonic for building back-ends

Leave a comment

Conclusion

It’s easy to make bad choices with such an abundant quantity of different technology blocks.

An application can be logically (and physically) divided into layers.

The three-tier architecture divides an application into a presentation, business, and data layer. The hexagonal architecture separates the application (including business logic) from all types of integrations (including presentation and data access). This makes this type of architecture more flexible.

Libraries, frameworks, cloud APIs, and low-code platforms are all components containing reusable functionality. They all strive to solve common problems in an easier way.

Selecting these components should be done wisely. They all have their advantages and disadvantages. It’s critical to start from the non-functional requirements during evaluation.

Subscribe now

Vision, mission and core values are at the heart of a company. They are present on most companies’ “about page”. They are also usually featured on companies’ “career pages”. Everyone has heard about them and everyone has been exposed to them.

Still, I am wondering how many people really get what these are all about.

I have to admit that even while I am writing this very sentence, it’s difficult for me to really nail the difference between mission and vision.

From my experience, it frequently happens that employees have no clue what the “values” are of the company they are working for. It also occurs that employees don’t recognize the values published on their company website. What is written does not match what employees experience.

My online research grew my confusion. Different sources define vision and mission differently.

This is my attempt to demystify what the vision, mission, and values as the foundation of a company actually are. You will learn about their components like their roles, target audience, and what they influence or guide.

I will also present a step-by-step guide on how you can start drafting your own mission and vision statement including the core values.

It’s not only useful to create these statements for a company. It’s also very helpful to create mission and vision statements at a team level to guide and communicate the strategy to everyone involved.

You can also use the guide to get more insights about what you as an individual want to accomplish and what you truly value.

💡 Let’s first head over to the Cambridge Dictionary for some definitions.

Looking for Clarity

I found a couple of dictionary definitions that are roughly matching my current understanding of a vision:

an idea or mental image of something

The ability to imagine how a country, society, industry, etc. could develop in the future and to plan for this

And for mission:

Any work that someone believes it is their duty to do

And finally for values:

The beliefs people have, especially about what is right and wrong and what is most important in life, that control their behaviour.

The Roles of Mission And Vision Statements

Mission and vision both relate to an organization’s purpose and aspirations

Mission and vision statements together play 2 critical roles:

• Communicating the purpose of the organization to stakeholders

• Providing a high-level guide for the strategy

Mission Statement

A mission statement communicates the organization’s reason for being and how it aspires to serve its key stakeholders.

A mission statement answers the following questions:

• “What’s our reason for being or why do we exist?”

• “How do we aspire to serve our key stakeholders?

• “What do we as a company value?”

The stakeholders are the key parties who have some influence over the organization or stake in its future e.g. employees, customers, and investors

Look at this example from Lemonade:

“Transform insurance from a necessary evil into a social good. We’ve designed Lemonade to bring out the best in people while giving society a push for the better.”

Vision Statement

The vision statement is a distilled future-oriented VERSION of the mission. Given the mission statement, the vision statement answers or highlights:

• “What does our company look like once we achieved our mission?”

• “What does the world look like once we achieved our mission?”

The strategy flows directly from the vision since the strategy is intended to achieve the vision and thus satisfy the organization’s mission.

Being future-oriented, a vision statement can really help to inspire and motivate people working towards the dream future for the company. A well-communicated and easy-to-understand vision can definitely boost employee engagement levels.

Take this example from Airbnb. Here the vision statement is only a more narrow version of the mission statement. The mission already includes the vision.

• Mission Statement: “To live in a world where one day you can feel like you’re home anywhere & not in a home, but truly home, where you belong.”

• Vision Statement: “Belong Anywhere.”

What About Values?

Core values are part of the mission statement. The format of a mission statement can differ and often companies use different formats to communicate the same thing. Sometimes:

• the values are summarized in the mission.

• guiding principles are added to elaborate on the organization’s values.

Values dictate behavior. They have to include verbs. They have to be actionable. It is not possible to execute based on the word “innovation”. “Look at the problem from a different angle” is something that you can do.

It has to be possible to decide what is right and wrong behavior based on these values. They should be used to guide employee behavior.

Values can also be an emotional touch point for your customers.

Let’s give some examples.

Examples

Patagonia

Patagonia summarizes the core values in the mission statement.

“We’re in business to save our home planet.”

Via its website, Patagonia has chosen to only communicate its core values. All of them together can be viewed as an elaborate version of the mission statement.

• Build the best product

• Cause no unnecessary harm

• Use business to protect nature

• Not bound by convention

Patagonia is a great example of a company that creates an emotional touch point for the customers. People that really care about creating a sustainable environment will appreciate the brand Patagonia together with its products.

Patagonia has not officially published a vision statement. The added value of a vision statement can be limited since the vision statement is a distilled or sometimes tagline version of the mission statement.

Starbucks

This is the mission statement from Starbucks:

to inspire and nurture the human spirit – one person, one cup and one neighbourhood at a time.

For more clarity, Starbucks also adds guiding principles that communicate the company values.

What follows are two of their guiding principles.

“It has always been, and will always be, about quality. We’re passionate about ethically sourcing the finest coffee beans, roasting them with great care, and improving the lives of people who grow them. We care deeply about all of this; our work is never done.”

“When we are fully engaged, we connect with, laugh with and uplift the lives of our customers – even if just for a few moments. Sure, it starts with the promise of a perfectly made beverage, but our work goes far beyond that. It’s really about human connection.”

Step-by-Step Guide

1. At first don’t think too much about what belongs in the mission, the vision, or the values. Answer the following questions instead.

   • Problem: What problem does the company want to solve? Or what unmet need does it want to satisfy? Why exactly?

   • Outcome:

     • Business outcome: What does our company look like once we solved it?

     • Customer outcome: What does the world look like once we solved it?

     • What is more important? The business outcome or the customer outcome? Why?

   • Guiding Principles: What does the company value? List 4 to 6 guiding principles about how the company operates. You should describe:

     • What does the company feel is most important?

     • What behavior does the company want to promote?

     • What behavior does the company really want to avoid?

2. The guiding principles are your elaborate version of the core values.

   • Values = Guiding Principles

   • Summarize each guiding principle in a couple of words. Make sure it is actionable and it includes a verb.

3. Define the mission:

   • Mission = problem + most important outcome + summary of guiding principles

   • Can you generalize the values into one value? Is there one theme? What is the most important one?

4. Define the vision:

   • Vision = a narrow version of the mission that focuses on the most important outcome

   • Describe the most important outcome in a couple of words. Write it as a tagline.

💡 You can also duplicate this Notion Template to start drafting your own mission and vision statement.

Conclusion

It’s easy to confuse mission and vision statements even though they are (or should be) at the heart of every company. The mission and vision statement both relate to an organization’s goals and hopes for the future. Together they communicate the organization’s reason for being and they provide a high-level guide for the strategy.

The mission statement includes the core values which describe what a company feels is important. Values should be actionable and be used to guide desired behavior.

The vision statement is a more narrow future-oriented version of the mission. It describes what the world looks like once the vision is achieved and this mission is satisfied. Sometimes the mission statement already includes the vision.

Last but not least, I presented a step-by-step guide for drafting your own mission and vision statement including the values. It can be used at the company level, team level, and individual level.

Subscribe now

Building software solutions can be challenging, even for experienced software engineers.

The best engineers are very pragmatic and masters at selecting the best tool for the job. They are great at coaching juniors. They like to convert complex problems into easy-to-understand solutions. Their efforts result in maintainable and extendable code. They help new team members to become productive in a short time frame.

If you don’t like the idea of building useless software or software that costs multiples of what it will ever return, then this article will be interesting for you.

Working with technology is not that hard for an experienced software engineer. One thing I feel, that makes it challenging, is the disconnection between the business and software engineering.

Technology is dependent on business strategy and goals. If you don’t understand the business:

• How can you be confident in making the right technology decisions?

• How can you make sure the project succeeds?

• How do we even measure success?

I know it is not the job of a software engineer to define the business strategy or the business architecture. The goal of this article is to help software engineers and their leaders with creating valuable software solutions that are aligned with the desired business outcomes. This information can also be used to challenge the business about what they are asking you to build.

If you are solving the wrong problem, it doesn’t make a difference if you’re the best at writing beautiful and maintainable code.

Disclaimer: My background is in software engineering, I don’t have an MBA. I’m just very interested in creating valuable software. In order to create valuable software, I feel it’s necessary to know how a software solution fits into what a business wants to achieve.

Decomposing The Business

I like to decompose things in order to better understand their internal components. A business can be viewed as a function. You feed the business input, the business processes it, and finally, the output is generated. If you change the input or the process, another output is generated. A business can grow and a business can shrink.

A business is a process where resources are used as input. The outcome is the output of the process. Output is not the same as outcome. The business strives to maximize the outcome.

Two things can increase the outcome:

• change in resources (sometimes less is more)

• improved efficiency of the business processes

Outcome

Output, outcome, and benefit are all related but they are definitely not the same.

Output: The product, service, feature, or result created by an initiative. Example: The new company website explains the advantages of the created products.

Outcome: The result of the change derived from implementing the project. Example: Shorten the average sales cycle time by 30%.

Benefit: The measurable benefit resulting from an outcome. Example: Increase sales revenues by 10%.

For any business, there are two categories of desired outcomes: your customer outcomes and your company outcomes.

While they are very different, you must not prioritize one over the other. You must work on achieving both simultaneously or you will fail on both fronts. Going overboard on either prevents you from achieving long-term business success!

Some examples of desired outcomes for your business:

• Profit

• Customer value added

• Shareholder value added

• Customer retention rate

• Employee morale increased

And some examples for your customer’s business:

• Cost reduction

• Equipment uptime

• Create peace of mind for the buyer

• Permit innovation

Business outcomes influence the input of the business process. Outcomes can be positive or negative. The image below presents a simplified sketch of how business and customer outcomes fit in the overarching business.

The business strategy determines the desired business outcomes and customer outcomes. Measurable benefits can be used to track progress towards the desired outcomes.

It’s important to question how solution initiatives relate to desired business or customer outcomes. If no one can answer this question for you, then you might start preparing for failure even before the initiative has even started.

Resources

Let’s investigate the input of the business process. What helps to discover and categorize these inputs is The Business Model Canvas.

The key resources from The Business Model Canvas are necessary to create value for the customer and also indirectly for the business. They are considered assets to a company. They are needed to sustain and support the business. They are also important for growing the business. These resources can be categorized into four main categories:

• Physical resources: raw materials, buildings, vehicles, transportation, storage facility, machines, factory, …

• Human resources: staff, such as talented engineers or marketing experts. These resources are more important in companies in the knowledge-intensive and creative sectors.

• Intellectual resources: brand, patents, copyrights, partnerships, customer databases, customer insights, technology systems, software, and processes

• Financial resources: cash, credit, …

Bare in mind that key resources can also be acquired via partners (Key Partners from the Business Model Canvas).

Software (built or bought) is a non-tangible resource, which means that it can potentially be an important enabler for your business. But, it can also be a bad investment.

The Business Process

A business model describes how a business creates, delivers, and captures value back from its customers.

Business Process Phases

The business process goes through different phases unless you fail at a previous one.

• Problem-Solution Fit: You have evidence that customers care about certain jobs, pains, and gains. You don’t have evidence that they care enough to buy it.

• Product-Market Fit: A need is identified and validated in the market. The customers from that market are also prepared to buy what the business creates.

• Business-Model Fit: The value proposition creates value for your customers. The business model also creates value for your organization. The business model is now profitable.

Profitable businesses capture more value from the customers than it costs to create and deliver their products and services.

Decomposing the Business Process

We can use the definition of the business model to divide the business process into three sequential steps. Each subprocess includes people that do the work. These people use technology to make the work they do more efficient.

Creating, delivering, and capturing value are all primary activities or core business processes. They are essential for adding value and creating a competitive advantage. When further decomposing these processes, we can make make a distinction between core and supporting processes. The role of the supporting processes is to help make the core processes more efficient.

Examples of core business processes: product development, logistics, marketing, and sales

Examples of supporting business processes: accounting, finance, quality control, human resource management, procurement, and R&D

It’s important to know where a software solution is located in the business process. Is the solution part of a supporting business process or is it part of a core business process?

• When a clothing manufacturer sells manufactured clothes via a website, then that website is part of a core business process.

• When a software company has a public website for recruiting new employees, then that website is part of a supporting process. In this case, recruiting is not the core business. Recruits support the organization in becoming more efficient at the core business processes.

It is not because technology is part of a core business process that you should build it yourself. The company should do what the company is good at and for which it can access the right talent.

A technology solution that is part of a core business process should match how the business wants to differentiate itself. If you want to be the most convenient online business to buy a particular product from, then it is important that your website is convenient to use.

Core business processes create customer value. They should result in benefits for the customer.

Supporting business processes make the organization more efficient. They should result in benefits for the organization.

Challenging The Business

By now, you have the necessary foundation to start questioning a solution initiative. Make sure you collect enough information about the items underneath. If no one can provide you with this information, then prepare for failure and a waste of time.

1. The Problem: What problem is this initiative solving? It should include what’s going wrong, and why it is a problem. It should be clear what customer or business outcomes it relates to and if the problem is part of a core business process or part of a supporting process.

2. The Proof: Ideally you want proof of the problem. You want to avoid participating in wild guesses. Evidence should back up the problem statement. A combination of qualitative and quantitative data works best.

3. The Measurement: How will we measure the success of this initiative? For each outcome, one or more measurable benefits can be inferred. Quantitative data might show us where we are now. Now, where do we want to move the measurable benefits?

4. The Target Audience: Who are we building this solution for? Is this for employees or for customers? What kind of employees or what kind of customers?

People with the following roles should be able to provide you with answers: business architects/enterprise architects, domain experts, business analysts, product managers, and project managers.

Conclusion

It’s challenging to create valuable software solutions when there is a disconnection between the business and software engineering.

In this article, I have explained how I see the business at a macro level. Resources are used as input for the business. The business model processes the resources. The outcome is the output of the process. It represents the change result of implementing the software solution.

The outcome can be beneficial for either the customer, the business, or both. In the long run, it is important to balance customer outcomes and business outcomes.

A solution initiative is either part of a core business process or a supporting business process. Core business processes create value for the customers. Supporting business processes make the business more efficient.

As a software engineering team, it’s important that there is transparency and clarity about how a software solution fits into the business strategy. You should have at least an idea about the problem to be solved, what will make the solution successful, and the target audience of the solution.

At Sirris, we help you make better digital investments:

• We provide vendor-neutral guidance on how you can build valuable digital solutions and products.

• We focus on people and processes and never look at technology in isolation.

Schedule a free conversation now if you want to maximize the impact of your digital initiative.

Free Conversation

Subscribe now

During the creation and delivery of software, businesses often focus on the features of their product. Customers on the other hand are looking for solutions and how that particular solution will improve their life.

I really like how the people from UserOnboard showcase the relationship between the product a business produces and the customer looking for a solution.

People don't buy products. They buy better versions of themselves.

When you're trying to win customers, are you listing the attributes of the flower or describing how awesome it is to throw fireballs?

It’s not because you buy a product that it will completely fit your needs. Very often customization or extension of the product is required. Often the product is only a (small) part of the complete solution the customer needs.

To be or stay successful, businesses that are building solutions have to constantly look for ways to reduce costs, deliver working software faster, and meet or exceed their user’s needs.

But also, I’ve been part of projects or product teams where:

• we built solutions no one wanted or did not meet the needs

• we delivered slowly and introduced bugs frequently

• the cost of creating solutions was higher than it should be

In this article, I will talk about the software development process, the people doing the work, and the kind of technologies that are used. The information can be used as a high-level blueprint for which the different parts can be adjusted to your specific needs.

Why Is This So Hard?

The number of different technologies for creating software is rising. The amount of highly skilled engineers that can work with advanced technologies is small. Skilled software engineers seem to prefer to work in high-tech environments instead of building domain-specific solutions that are less complex in terms of technology. The total group of traditional software engineers is too small for the increasing demand for digital solutions by businesses.

An enormous amount of low-code and no-code tools for creating software are already available. These tools are aimed at less skilled developers. It’s often not very clear what’s possible with these tools and what skills are necessary to effectively use these tools.

Under certain circumstances, it will make sense to opt for a no-code or low-code strategy for building a solution. Sometimes due to the complexity of the project, custom high-code written by skilled software engineers will be needed. And sometimes a combination of strategies is the best choice.

Businesses often rush to solutions and technologies for building software too quickly. They are usually sold on the sole idea that developing software needs less skilled resources and won’t take a lot of time.

Creating software is not only about writing code or drag-and-dropping components.

The chosen development strategy sometimes lacks quantitative and qualitative support. This increases the risk of a bad outcome for the customer (internal or external), the business, or both.

Bad choices are most often a people problem while all the technology is working fine. The tech just doesn’t fit your needs.

Creating Software Solutions

Businesses are constantly looking to improve the process of creating and delivering working software. This means:

• reducing costs

• improving the speed of delivery

• meeting and exceeding customer’s needs

The smoother the process runs, the better the above goals can be achieved.

The process of creating a software solution always includes people and technology. A software solution is equal to the process outcome of how people are working with each other and interacting with technology.

Solution = Process (People + Technology)

The (SDLC) Process

The software development life cycle (SDLC) is a process that helps to quickly develop high-quality software ready for production. When researching this process, diverse sources mention different steps. The number of steps is always somewhere between 5 and 8.

I personally like the steps shown in the picture below. No matter if you choose an Agile or Waterfall approach of the SDLC, all these steps are important and they all deserve enough attention. Choosing the best SDLC implementation is dependent on many things. Some of them are the needs and complexity of the project and the business.

1. Strategy

A project should always include a vision and a direction of the envisioned solution over time.

The first phase is about crystalizing the problems that need to be solved. It’s also essential to:

• have a deep knowledge of your target audience.

• look at the alternatives your target audience has including what competitors are offering.

A good strategy and clear goals will create focus, clarity, and alignment for all people involved in the initiative.

If you get this phase completely wrong, you will end up building software that no one wants (bad enough) and will not be used (enough). All the effort put into the next steps will be a complete waste of time and money.

2. Design

The design phase is about clarifying technical and functional requirements.

Technical requirements include:

• a description of the software quality attributes the solution needs to have. Some examples are maintainability, reusability, security, and scalability.

• a high-level architecture and what important building blocks are needed. Examples of building blocks are:

  • Programming Languages (Java, C#, Python, …)

  • Products (SaaS, Open Source, Databases, Deployment Environments, Low-Code, No-Code…)

  • Frameworks

An end-solution is comprised of many different products, custom development, and integrations.

Functional requirements are about what needs to be implemented so that the users of the solution can achieve their goals. Prototypes are often built to better understand what the end solution should look like and how it should behave.

3. Development

During this phase, the software engineering team builds the necessary features that are in scope using the chosen technologies.

There are multiple ways for building features:

• In high-code environments, the features are built by writing code.

• In no-code environments, building features happens by configuring pre-built components.

• Low-code development is a mix of high-code and no-code.

4. Testing

This vital phase tests the software to ensure everything works as expected. Defects are fixed when they are discovered.

Three important types of testing exist:

• Unit tests test individual components of an application in isolation (without any interaction with dependencies) to confirm that the code is doing things right.

• Integration tests check if different components are working fine together. Real dependencies are used.

• Functional tests test a slice of functionality in the system to confirm that the code is doing the right things. Functional tests often have dependencies.

5. Deployment

Software deployment includes all processes that ensure a software system or update is available to the users. Usually, this includes software release, installation, testing, deployment, and performance monitoring.

Often different environments are required. You need at the very least 2 depending on the kind of platform that you are using and the complexity and needs of the solution.

Deployment pipelines enable versioned artifacts to be pushed to higher environments. It’s also beneficial that rollbacks to previous versions can happen easily.

6. Maintenance

The lifetime of the solution is not at its end once the solution is deployed. It’s called the software development life cycle for a reason.

In this phase, the development team processes feedback and fixes bugs discovered by users or stakeholders, and provides ongoing enhancements. It’s often crucial that the end solution can be easily customized when changes are needed.

Make sure that enough people have the necessary knowledge and skill to maintain the solution.

People And Technology

People should always have the required skills to work with a specific technology. You can hire professionals that are specialized in that technology or you can train people so that they acquire those skills on the job. It often happens that training is underestimated.

Creating a website is much easier than it used to be. Unless you need something very specific with complex integrations and an advanced user interface, most people can already do this by themself.

Not so long ago, access to people with advanced skills was a prerequisite to building a website. You needed to have a deeper knowledge of user interface design, front-end and back-end programming, databases, networking, and infrastructure.

Nowadays, there are SaaS solutions where non-technical people can start from a template based on the goal of their website. All they have to do is tweak it a little bit by configuration instead of programming.

Everything is hosted and managed by the vendor. It’s robust, scales automatically, it’s secure, and it’s also cheap. Your job is to focus on the content for your site and the message that you would like to send. And even there, the templates are helpful for providing ideas.

These SaaS solutions have free versions which often suffice to start from. You can easily upgrade to a premium version when you need more advanced features to accomplish what you want. Even those premium versions are ridiculously cheap compared to the early days of building websites.

This story is a simple example of the democratization of technology.

Democratization of Technology

The democratization of technology means that over time more people have access to specialized knowledge without the need for extensive training.

Building things with new technologies entering a market cost a lot of time and money. The volume of things created with the technology is relatively small and the rate at which they’re made is small.

Over time, the technology advances and gets packaged in ways that require less expertise in the technology itself. It gets easier to apply the technology in the context of a particular domain. People need less advanced skills to take advantage of the technology.

The cost of creating things with the technology drops. The volume of things created and the rate at which they’re created rises.

Stages of Technology Democratization

This paper shows that there are five stages that technology goes through as it is being democratized. The stages can be identified by different groups of people.

1. Discipline Experts: Tech professionals who are primarily masters of the core technology, independent of the domain in which it is applied. Often small tech-savvy startups are deploying sophisticated forms of technology.

2. Domain Experts: Tech professionals who master the technology in a particular domain, e.g., marketing technologists who build solutions within the marketing department.

3. Power Users: Non-tech professionals who develop advanced technical skills in leveraging the technology, e.g., tech-savvy marketing automation platform administrators.

4. Users: Non-tech professionals, people who are not experts in a particular discipline, can use tools to accomplish tasks in those disciplines. For example, new technological tools enable non-IT experts to build websites themselves.

5. Ambient/Automatic: Technology just works within the domain without users needing to explicitly manage/operate it, e.g., where automation or AI simply take over the work.

Democratization of Software Development

Developing software is part of the democratization of technology. That’s also why we hear the term citizen developer a lot nowadays. Citizen developers are not professional developers but rather tech-savvy domain experts.

People with advanced skills are becoming more scarce. The demand for professional skilled developers is enormous at the moment. Due to the democratization of technology, more people with limited skills can participate in the process of building software solutions.

Software engineers will never become redundant. They will need to build the development platforms and tooling so that less skilled users can create software solutions.

Leave a comment

Conclusion

When building a solution, it’s important to focus on the benefits for the end-user instead of focusing on the features of a product. Building solutions that don’t meet the user’s needs is just a waste of time and money.

The Software Development Life Cycle process is an abstract and circular process that consists of multiple steps. There are many ways to implement it. All the different implementations need to take into account the following steps: strategy, design, development, testing, deployment, and maintenance. Choosing the best implementation of the SDLC process is dependent on many factors. These include the complexity and the needs project, and the business.

The process of creating a software solution always includes people and technology. People should always have the required skills to work with a specific technology. Software development is part of the democratization of technology. The democratization of technology means that over time more people have access to specialized knowledge without the need for extensive training.

There will always be a need for software engineers. They will enable software solution building for less skilled users.

At Sirris, we help you make better digital investments:

• We provide vendor-neutral guidance on how you can build valuable digital solutions and products.

• We focus on people and processes and never look at technology in isolation.

Schedule a free conversation now if you want to maximize the impact of your digital initiative.

Free Conversation

It is sometimes tough to get things done in a workday. I’ve experienced days where it felt like I accomplished nothing.

This is an example routine from my past and some parts might sound familiar to you:

• The workday starts somewhere between 8 and 9 AM. There is a standup with the team at 10 AM. It does not make sense to start with anything before that meeting that requires a huge amount of brain power.

• I decide to go through my emails. It’s a bad habit but I’ve already scanned some of them the evening before while sitting on the couch in the living room. One email seems to require my attention ASAP. It contains a chain of messages and people located on the other side of the world are replying as we speak. This will require some thought and investigation tomorrow morning. There is no use to answer immediately unless I power up my laptop.

• After the standup, I decide to check what I missed on Slack. This is often the place for essential discussions. I feel it’s important that I can also share my opinion and the decision might also impact my work.

• I still need to take some time to review a couple of documents stored on Google Drive and comment on those. I also need to file a bug report.

• At 12.30 PM, I take time for a quick lunch.

• This is followed by 2 meetings in the afternoon with a half hour in between. One meeting is an unexpected one, I only see a subject but it isn't easy to gauge what it is really about.

• After the meetings, I check my notifications on Slack and new emails arrived.

• Before I know it, it’s 5 PM.

Tomorrow, I will be able to “brag” about how busy I was at the standup. But at the same time, I’m thinking about the limited value I have been creating or the impact I had. There was also no time for engaging with deep work.

For deep work that needs creativity, out-of-the-box thinking, and brain power to tackle complex problems, I need to get “in the zone”. The best time to enter the zone for the schedule I presented is before 8 AM or in the late afternoon. The fewer distractions I have, the better it is to sharpen my focus.

The days I’m working from home, often result in longer workdays but at least then I’m getting things done.

I like going to the office from time to time. At the office, It’s nice to meet up with colleagues but I’m frequently absentminded because there is more noise and more unexpected conversations. Commuting also takes time. I get generally fewer things done at the office.

This made me ponder and reflect some more. I also did some research and gained some insights.

This article shows how companies that heavily depend on knowledge workers, can drastically improve their business outcomes. I will show what these companies can learn from remote-first companies and how your business will be able to achieve more with fewer people.

Wasting Time

I discovered an interesting collaborative study from Asana and Sapio Research. That study shows that knowledge workers are doing meaningful work for only 2 days out of five. Continous emails, message notifications, and unexpected meetings consume 60% of a worker’s day.

At a time when it is challenging to find skilled talent, an enormous amount of time seems to be wasted with the talent that companies do have at their disposal. Next to being on the lookout for additions to the current workforce, it’s also vital to investigate how current work processes can improve.

According to the study, this is where knowledge workers spend their time on:

• Only 27% of the time is spent on the skilled job they’ve been hired to do.

• 13% of the time is spent on strategizing and planning.

• A staggering 60% is spent on coördination such as communicating about project status, searching for information, and managing shifting priorities

This demonstrates that there is room for improvement. It’s difficult to do deep work when your time is limited and you have to switch between tasks all the time.

About Interruptions

People are not like computer processors. We are not able to switch between tasks as easily and efficiently.

According to this study from the University of California, it takes on average 23 minutes and 15 seconds to get back to a task after being interrupted. If you get distracted three times a day, you lose an hour of work.

The more complex the task at hand, the longer it takes to get back into the zone. Software developers for example lose more time returning to a task than average knowledge workers. The longer they are away from a task, the more time is needed to get back to it. Non-technicals often have trouble understanding how much focus a developer needs to execute his tasks.

Paul Graham wrote an article about the difference between the maker’s schedule and the manager’s schedule:

The manager's schedule is for bosses. It's embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you're doing every hour.

Since the manager is often calling the shots and is not fully aware of this, makers have less time for deep work and getting things done.

When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting.

The Case For Deep Work

In this article, Cal Newport, author of the book Deep Work talks about the difference between shallow and deep work.

Knowledge workers dedicate too much time to shallow work — tasks that almost anyone, with a minimum of training, could accomplish (e-mail replies, logistical planning, tinkering with social media, and so on). This work is attractive because it’s easy, which makes us feel productive, and it’s rich in personal interaction, which we enjoy.

Knowledge workers should need to spend more time engaged in deep work — cognitively demanding activities that leverage our training to generate rare and valuable results, and that push our abilities to continually improve.

Cal mentions three key benefits generated by deep work:

1. Continuous improvement of the value of your work output.

2. An increase in the total quantity of valuable output you produce.

3. Deeper satisfaction (aka., “passion”) for your work.

Deep work has benefits for both the business and the employee. This is closely related to what I talked about in one of my previous articles: Boost your Business by Creating Happiness

The Five Levels of Remote Work

I am currently reading the book “The Pathless Path” by Paul Millerd. I also subscribed to his newsletter “Boundless”.

Boundless by Paul Millerd

Unexpected takes on the modern world of work. Paul explores our obsession with work and the default path of success and tries to imagine new possibilities for how we can conceive of life, work & what matters.

In one article he talks about the five levels of remote work, a concept introduced by Matt Mullenweg, CEO of Automattic, and also the company behind WordPress. Automattic is considered a role model and innovator in the area of remote work. It has been entirely remote since 2005, and with almost 2000 employees, it has helped prove that remote workplace culture can succeed at scale.

Remote-first companies have employees in different time zones all over the world. Employees also have the flexibility in deciding when to start and end their working day.

The biggest challenge that globally distributed remote companies are solving is … COMMUNICATION.

Since the pandemic, lots of companies were forced to adopt remote work quickly. Remote tooling like Slack, Teams, GSuite, Zoom and Miro were introduced.

Many of these companies are somewhere between level 2 and level 3 of the pyramid shown below. These companies are remote-friendly and offer the flexibility to work from home. Most companies still expect their employees to come into the office at least some of the time. But apart from the flexibility, there are no significant business advantages.

A company starts to witness the real power or remote working once it is operating at level 4. At that level, REAL asynchronous communication is used.

When reaching level 4, the company can call itself remote-first. Remote-first isn’t the same as remote-friendly. Remote-first is a whole new way of organizing a company. I start to roll my eyes when I see job descriptions where a company is offering the flexibility to work from home 2 days a week. In that case, working from home will most likely result in more trouble collaborating.

How many of you enjoy “hybrid meetings”? How included do you feel in such a meeting?

It’s NOT about Remote Work

An article on TechCrunch mentions that Automattic rejects the word “remote” entirely. Instead, Automattic uses words like “distributed” and “asynchronous”. Communication at Automattic is written and asynchronous.

Asynchronous means that it can be addressed anytime during the work day. This is in contrast to communication where an answer is expected (almost) immediately.

These are some examples of synchronous communication:

• All kinds of meetings: virtual (e.g. Zoom), hybrid, at the office

• Tapping someone on the shoulder at the office to ask a quick question

• Phone calls

These are examples of asynchronous communication channels:

• Emails

• Instant Messaging: Slack, Microsoft Teams, Google Hangouts

• Collaborative Designer Tools: Figma, Marvell

• Async Video Messaging: Loom

Email and instant messaging are asynchronous communication channels by nature. How these remote tools are used, is influenced greatly by company expectations and culture.

These are things that are happening at companies with remote and “asynchronous” tooling but are not remote-first:

• You are expected to be online in Slack or Teams. Otherwise, your boss might think you are not working.

• You are supposed to follow up on IM notifications on many channels (even if the messages posted over there are not business critical).

• People video call you out of the blue and you are supposed to accept them.

• You are expected to have your email client open.

• Email is the primary method of communication. Most of them result in long message chains.

People are Different

Chronotypes

Not all individuals have the same sleeping pattern. Some people are more energized in the morning, others in the evening. Generally, people can be allocated to one out of 4 “chronotypes”.

The following animal names are used to represent these chronotypes: the lion, the dolphin, the wolf, and the bear.

It seems that I’m a wolf. I like the snooze button and have trouble waking up. I also perform at my best later in the day. This holds for doing sports and for engaging with complex or creative work.

Even when people are living in the same time zone, they are performing better at different times during the day.

Introverts and Extroverts

Introverts think best when it’s quiet and where there are no other people around. Meetings are challenging for them, speaking before large groups can be especially intimidating for them too.

More preparation and written communication are beneficial for introverts. It also benefits the company. Introverts thrive more when they can think in solitude. It will also lead to better decisions where everyone participates more equally in the discussions.

Remote-First

What’s happening at a remote-first company? I studied some companies that operate fully remote and sell remote-first products.

Ditch Recurring Meetings

Meetings are reduced to an absolute minimum. Recurring meetings are ditched and replaced by asynchronous communication. Recurring meetings are often about accountability.

Some examples:

• Standups: “What did you do yesterday, what are you going to do today, any difficulties?”

• Reporting: “What’s the status of the project?”

• Announcements and updates: “We landed a new enterprise customer!“

Use Asynchronous Video Calls

With tools like Loom or Claap, it is possible to replace a whole range of meetings with video recordings. These tools allow you to give contextual feedback to one another and have discussions inside that tool. It is for example possible to put comments or ask for input at a certain moment in time of that video.

These tools can be used for a whole range of interesting use cases:

• Centralizing and sharing team knowledge

• Collaborating asynchronously

• Asynchronous team planning

• Delivering feedback faster

• Training and building teams

• …

What Meetings to Keep

• Social bonding: offsites where the whole team meets in person for a combination of work, fun, and offline connecting. Donut chat helps to welcome new hires, build internal networks and virtually meet “strangers” for coffee or lunch.

• Manager check-ins: It’s beneficial to organize a 1-on-1 between a manager and a direct report synchronously. This can be done via a video call.

• Hiring: Some parts can happen in writing but at a certain point, it’s best to meet in person using a video call.

• Customer Meetings: Gathering qualitative data and feedback from customers often requires a live meeting.

Email and instant messaging tools like Slack are asynchronous but they have some real disadvantages:

• They bury information. You might miss important discussions when being out of the office for a couple of days or just plain busy.

• The information is not well organized and it’s difficult to find the necessary information after a while.

Tools like Twist are betting against Slack for exactly those reasons.

Conclusion

The remote-first model is beneficial to all companies that heavily depend on knowledge workers. Companies can achieve more with fewer people. This is particularly interesting since it is so hard to attract top talent.

On average, knowledge workers only do meaningful work 2 days out of five. The main reason is that they are frequently distracted and interrupted. The more interruptions, the harder it is to engage with deep work. More time for deep work is beneficial for both the employees (more satisfaction) and the company (more value).

People are different. They do their best work under different circumstances and at different times during the day.

• Meetings are challenging for introverts. They benefit from more preparation and written communication.

• Some people feel more energized in the morning, others in the evening.

Remote-friendly offers flexibility to employees to work from home. These companies still have an office-first culture which makes collaboration more difficult. Remote-first is not only about remote work. It’s mainly a different culture.

At remote-first companies:

• Recurring meetings are ditched

• Some meetings are replaced by asynchronous video calls.

• Hiring, manager check-ins, customer meetings, and social bonding are exceptions for organizing meetings.

• Email and instant messaging tools are replaced by tools that promote structure and do not bury information.

I would also like to hear YOUR thoughts or questions about this topic:

• How much can you engage with deep work at your job? What would help to achieve better focus and greater satisfaction?

• At what level of remote work is your company operating?

• When during the day, is your best time to do creative or complex work? What is the best environment for this type of work?

• Which remote tools are your favorite ones? And why?

• How many meetings do you have on average each week? How many of them do you think are necessary and which ones could be replaced by writing?

A couple of years ago, I moved away from software engineering. Failed or abandoned transformation projects were the main reason.

There was the occasional benefit of playing with new technologies. However, I was sick of spending months or years creating something which did not provide any or enough value. I wanted a role with more impact and more chance to prevent these failures from happening.

I guess it's no surprise but my team was not the only one experiencing failed transformations. It appears that an astonishing number of corporate transformations fail.

In this article, I will talk about why digital transformations fail, what’s wrong with the traditional way of working, and how an organization can beat the digital transformation odds.

Subscribe now

Some Numbers

Harvard Business Review mentions that three-quarters of digital transformations fail. In 2016, Forbes assessed the risk of failure in digital transformation to be 84%. According to McKinsey, BCG, KPMG, and Bain & Company, the risk of failure varies between 70% and 95%.

Many businesses seem to blame inadequate implementation for failure. They try to mitigate future failures by placing more focus on execution. While it’s true that flawed execution leads to a bad outcome, it is only one part of the problem. Many change initiatives also fail because of misdiagnosis.

Focus on the What

I think we can all agree that Albert Einstein was quite a smart guy.

This is one of his famous quotes:

If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and five minutes thinking about solutions.

This learns us that we should avoid jumping to solutions and start thinking about the problem first. We should first focus on deciding WHAT problem should be solved before focussing on HOW to solve that problem. Following Einstein his advice, everything discussed in this article will be solution agnostic.

It’s a People Problem

It’s important to get more insights into these transformation failures before diving into the steps required to mitigate those failures. I did some research and I bumped into this interesting article. It does an amazing job summarizing the reasons why projects fail.

According to the article, one main reason for failure is the lack of a solid business case supported by quantitative and qualitative (financial) data. This lack can result in:

• Prioritization based on politics

• Shiny toy syndrome that leads to the wrong technology choice

• No alignment with business outcomes

• Slow-decision making process

The business case should also be a team effort and all stakeholders should be involved. If you have no or minimal buy-in, it will be tough to succeed. Some things that can happen:

• Employees will sabotage the initiative because of the fear of being replaced.

• When people don’t understand what you want to achieve and what the benefits are, they will reject new tools, software, and processes.

Someone should also be responsible for the initiative that does not get lost in implementation details but focuses on the high-level goals. Some managers focus too much on details and lose sight of the bigger picture.

The important takeaway here is that most of the time the technology is doing just fine, but the people are getting in the way of success.

After examining and agreeing to this, I kept on questioning what the underlying cause could be. I came to the following conclusion for myself.

Business cases that are initiated by project managers that are operating in an organizational silo are a major recipe for disaster

This is a great point in favor of BREAKING DOWN THE SILOS.

Breaking Down the Silos?

What is a business case? This is the description according to projectmanager.com.

A business case is a project management document that explains how the benefits of a project overweigh its costs and why it should be executed. Business cases are prepared during the project initiation phase and their purpose is to include all the project’s objectives, costs and benefits to convince stakeholders of its value.

This is a great summary and it’s also more or less what I have experienced in past projects. The quality of business cases was often not great. I also recognize some of the failure symptoms of a digital transformation presented before.

Guess what? I was operating in a siloed organization before and the business cases were initiated in that silo. As already mentioned, business cases were often inferior. They were vague, biased, focused on a specific technology, and were not supported by qualitative or quantitative data.

It would be easy to blame the project manager. However, these flawed business cases are not only the fault of the project manager:

• He is expected to initiate business cases.

• He feels responsible to land the necessary budget and work for other team members from the same siloed team.

• There are often close deadlines for business case submissions.

• It’s difficult to present the best solution because the team has no helicopter view over the company.

• Very often quantitative and qualitative data for supporting the business case is also out of reach.

If I have to guess the root cause of these bad business cases, it is the company. The company is often what causes the problems for the silo including inferior business cases.

A company that operates in a silo nurtures employees to care less about the company as a whole. Employees are loyal to the silo and its objectives. The employees also lack information about the other silos.

For a higher success rate, business cases should be initiated at the level of the business. These initiatives can, later on, be decomposed into multiple lower-level projects. Teams can then further develop these projects. Working in silos makes everything more difficult and will lead to at least some of the problems mentioned before.

Helicopter View

The first challenge to succeed as a company is to pick the right battle.

A business capability model is a great tool to make the right strategic choices on where to focus first. I see it as a helicopter view of WHAT a business does independently of processes, technology, and organizational structures.

Be aware that all these three elements (people, processes, and technology) should be kept in balance to maximize the efficiency of a business. That same balance holds for each business capability.

If you want an example overview of a business capability model to get you started, check out this page.

I will also add some quick definitions for better comprehension:

Business capabilities are the functions a company needs to execute its business model. Business capabilities tell what a company does independently of processes, technology, and organizational structures.

A business model describes how you create, deliver, and capture value back from customers.

Capabilities can be categorized:

• Strategic: The things that the organization does well that sets it apart in a meaningful way. These offer the company competitive differentiation

• Core: These are part of the business model and relate to the creation, delivery, and capture of value.

• Supporting: These support the core or strategic capabilities. They don’t directly create value for customers. But they are a necessary prerequisite for running an organization. 

This capability model is a great asset in the following scenarios:

• Knowing where to invest and devest

• Prioritizing initiatives

• During mergers and acquisitions

• When buying products or building new solutions

A digital transformation can be focused on either core, supporting, or strategic capabilities.

All of them can lead to either financial or non-financial benefits. Some examples:

• Financial: Cost avoidance or reduction, Productivity improvement, Revenue/Sales

• Non-financial: Accelerated investment, Employee experience & satisfaction, Expansion

It’s critical that the strategy of the company and the focus of the digital transformation are aligned.

Conclusion

An impressive number of digital transformations fail. The tech is often not the problem, the people are.

There are some things you can do to increase the chance of success.

• Don’t jump to solutions, focus on the WHAT first before exploring the HOW

• Breaking down the silos will help to create team-wide focus, involvement, alignment, and understanding

• Digital transformation initiatives should be initiated at the business level where a helicopter view is present

• These initiatives should be aligned with the company strategy.

A business capability model is a great and diverse tool to assess the state of business capabilities and to discover WHAT should be improved.

Learn More

• How to create a capability model by Raj Ramesh

• Business Capability Heatmaps

• People, Process, Technology: The PPT Framework, Explained

I am always looking forward to hearing your thoughts about this topic:

• What do you think contributes to success or failure in a digital transformation project?

• How do you or your company select what should be improved as part of a digital transformation?

• Are changes at your company triggered by technology or by problems?

That essay warns aspiring founders that they should be very committed to the mission of their business if they want a chance to succeed. It’s actually a little bit scary, especially the part where Paul talks about a start-up being all-consuming.

Startups are all-consuming. If you start a startup, it will take over your life to a degree you cannot imagine. And if your startup succeeds, it will take over your life for a long time: for several years at the very least, maybe for a decade, maybe for the rest of your working life.

This made me think about the relationship between happiness and work.

So on the one hand, I was thinking that successful entrepreneurship and achieving happiness are hard to get right. Running a business requires so much from an individual. It seems almost impossible to stay happy when mental and physical health is often ignored.

On the other hand, I can also imagine that there is happiness in the journey of founders and their businesses. Reaching a vision or milestones towards that vision should bring at least some excitement and pleasure.

In this article, I will briefly talk about what happiness is and what exactly makes people happy. Then I will dive into who’s generally happier: entrepreneurs or employees.

Finally, I will demonstrate how it should be possible to boost your business by focusing on company-wide happiness. Sounds like a win-win isn’t it?

What is Happiness

First, let us focus on what happiness is. According to the Greek philosopher Aristotle:

Happiness is the meaning and the purpose of life, the whole aim and end of human existence.

It’s possible to interpret happiness in 2 ways:

• An emotion that can bring you intense pleasure, excitement, and satisfaction

• A long-term feeling of inner peace and contentment.

Aristotle was referring to that last one and it’s also that one that I will be referring to.

What Makes us Happy

I watched a talk this week by Daniel Gilbert about happiness. He’s a social psychologist and author of an international bestseller Stumbling on Happiness. So, this guy knows his stuff and everything he says is backed by science.

The talk provided some interesting insights into what makes us happy:

• Marriage makes us happy, but ONLY if it’s a good one.

• Children on average do not make us any happier. For younger people, single or divorced people, children actually make us (on average) unhappy. It seems that the harder you have to work for it, the less happy they make you. That’s also why men are on average happier when they have children compared to women.

• Money makes us happy when we have more of it. But the more you have, the less an increase impacts your happiness. So, when poor people become middle-class, they become a lot happier. On the other hand, If you are already rich and you become Bill Gates rich, it does not make you any happier.

What we do with our money also impacts our happiness. We become happier when we spend it:

• more on experiences and less on things

• more on others and less on ourselves

We become happier from spending the same amount of money on travel and dining compared to spending that amount on a fancy new car. When we buy a coffee or a present for someone else, it also makes us happier than buying the same things for ourselves. (So being cheap does not make you happy)

Work on average does not make us very happy, the same goes for resting. Even TV and talking to people make us on average happier than working and resting. So millionaires that only take naps on their shiny big boat are not necessarily happier.

In order to be happy, life needs balance. We should not focus exclusively on money alone, but also on our mental and physical health. Career, family, friends, exercise, and eating healthy should all be balanced if you pursue happiness. It’s hard to do a better job explaining this than Matthew McConaughy.

The whole point of this story is that we become happier from experiences and having a healthy and social life. Working and resting and spending your earned money on material things will not bring you any long-term happiness.

Are Entrepreneurs Happier than Employees?

Science shows a strong link between entrepreneurship and mental and physical health. Entrepreneurs are on average happier and healthier than employees. Money can buy happiness but only to a certain degree. According to this study, the biggest predictor of health and happiness is entrepreneurship.

What causes this, is the mindset of the average entrepreneur. Entrepreneurs are driven by a vision. They have autonomy and are more confident that even when things are uncertain, they will figure it out.

Employees can reap some of the same benefits as entrepreneurs by taking more control of their time and what they do with it.

As a Leader

While some might argue, I still believe that people are a company’s greatest asset. An inspiring vision helps to attract talent and to convince them to join your mission.

• Hire people that share your vision. People with a ton of scarce skills that don’t believe in the company's purpose are not a great fit. It’s better to have people with fewer skills, that are willing to work for it because they are passionate about the vision. Also, a lot can be trained on the job and by coaching them.

• Pay employees enough so they won’t leave you. Money is important, but it is not the greatest driver for employees. People are looking for a sense of mattering and autonomy where you as a leader trust them to get the job done. Pay them for results and not time spent. Don’t wait for them to increase their salary, take the initiative.

• As a leader, use a delegation framework. Aim to make yourself replaceable. Gradually give team members more autonomy. Be available when they need help and help them grow with the company. Make sure goals are visible and transparent and that they are aligned with upstream goals. Everyone should feel like they have an impact on the progress towards the ultimate vision.

Conclusion

In my opinion, the most important values to create a thriving business are autonomy, trust, and transparency. A transparent, visible vision aligned with cascading downstream goals will create a purpose for everyone in the company. Using a delegation framework and incorporating proper coaching will create growth opportunities and more balance in people's life. Everyone should also invest in their physical and mental health. Remember the quote from Peter Drucker:

Culture eats strategy for breakfast.

When working at a start-up, you can’t help but notice the passion, accountability, creative minds, sense of urgency, and speed of execution. When a start-up evolves into a larger corporation, they become slower and people often become too comfortable.

The trigger for this article is a blog post published by the insurance tech company Lemonade a while ago. The post explains how they were able to scale their headcount quickly using “The Company Model” while keeping all of the benefits of a start-up in place.

Lemonade’s headcount for example increased from 10 to more or less 1000 while expanding the size of its product offering from two to five.

Since Lemonade was founded in mid-2015, this growth is quite impressive. Building an autonomous organization is one of its pillars since its inception. The company is trying to automate everything it can so its employees can focus on more creative and challenging work.

In this article, I will first summarize what “The Company Model” is. Next, I will highlight what I think the secret ingredients are for scaling headcount rapidly. Finally, I will also cover if and how this model can work in a remote environment.

The Company Model

“The Company Model” as presented by Lemonade can be seen as an extension of The Spotify Model.

In both models, the organizational concepts of Squads and Tribes are used. The Company model extends this with the “Company” concept where each product is also governed by a “Company”.

Another difference is that “The Spotify Model” is limited to engineering and product teams, whereas “The Company Model“ is used beyond that. Lemonade for example also applies the model to Growth teams.

“The Company Model” does not exist solely out of Companies, Tribes, and Squads. There is also room for shared departments like “Finance, Infrastructure, Communication”. More about that later when I talk about the secret ingredients.

Squad

A Squad can be compared to a Scrum team. It is self-organizing and has a multi-disciplinary team that should feel like a mini-startup. With all the knowledge present in the Squad, it should be possible to deliver products or services from design to the final product. Every Squad has a long-term mission or objective.

Tribe

A Tribe is a group of Squads that are working on the same related products or services. A Tribe can also be seen as an incubator for new Squads. A new Squad can be introduced, when work for a new product or product feature is initiated. It’s like adding a Lego block to your Tribe.

Company

Since Lemonade has multiple products, they have added the concept of a Company. Each company focuses on a product. When they want to start developing a new product, a new autonomous Company is created. It’s again like adding a new Lego block to your organization. A Company consists of Tribes and Tribes consist of Squads.

The Secret Ingredients

Focus on (Cascading) Goals

There is a big focus on goals at every level of the organization.

The organization has a goal but this is also the case as we move downstream to the company, the tribe, the squad, and the individual contributor.

All these goals or objectives are aligned with one another. This makes it also very clear how every piece of the puzzle fits into the strategy of the company. At every level, the strategy is broken down further and further until there are clear tasks and deliverables that can be easily tracked and communicated. With this in place, every team member knows exactly how personal efforts impact the organization.

Conway’s Law

Conway’s law is empirically proven and states that:

Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure.

Within “The Company Model” communication is maximized inside Squads. As we move upstream in the organization, inter-communication between teams and teams of teams decreases. I think that this is a great way of balancing communication inside an organization.

Related Squads of the same Tribe need some communication because they are working on the same product and sometimes related features. On the other hand, no communication is needed between different Squads that belong to other Companies.

Different Companies also need to synchronize in some way in order to make sure the products don’t diverge too much and to enable cross-selling.

Supporting and Primary Teams

There is a clear distinction between supporting teams and primary teams. This is very related to the supporting and primary activities from the famous Porter’s value chain.

Primary activities contribute to a product or service's physical creation, sale, maintenance, and support. Supporting activities support the primary activities.

Everything that contributes directly to customer value is part of a Company. Everything that is supporting or indirectly contributing, is part of a shared department.

Value Teams

If we look back at the value chain presented just before, then we can see the different primary activities presented as silos. This makes me think of how traditional companies used to operate. In that case, there are different departments for sales, services, and engineering. Engineering is also divided based on the components they are working on.

In “The Company model”, there are no silos. Companies, Tribes, and Squads are all horizontal and accountable for achieving goals across the value chain.

Remote First

Unlike Elon Musk, I’m a major fan of remote work. It saves me an enormous amount of commuting time and it allows for a better balance between my private life and my career. I’m also very enthusiastic about traveling. With a limited number of holidays, I have to really think and plan everything very well. When I’m on a vacation, I don’t have time for slow travel. There is just too much to see or do and time is oh so limited.

The result is that I’m mentally rested when I return home but physically, I’m often exhausted. The idea to be able to work from wherever and whenever and that my work is evaluated based on results instead of exchanging time for money at an office desk, sounds like a dream come true.

But is all of this possible with “The Company Model” and is this also beneficial to the organization? Can this model be applied to fully-distributed teams across different time zones?

Agile Manifesto

“The Company Model” is a scaled version of Agile. Tribes from “The Company Model” (and “The Spotify Model”) are located near each other, often on the same floor of a building. That’s a huge difference from a setting where everyone works remotely from different parts of the world.

When inspecting The Agile Manifesto, it mentions motivated individuals, self-organizing teams, close collaboration, and a need for regular face-to-face conversations.

Nowadays, we have an abundance of modern tools like virtual meeting rooms, asynchronous communication tools, and digital whiteboards at our disposal. That is why I believe that the Agile principles can also be implemented in a fully remote company.

Culture

It is important however that the model matches the culture of the company and that such a culture is built early on. It’s a prerequisite that the company is adequately transparent, has good communication, and is based on trust.

Also more and more start-up companies are going fully remote. From a company perspective, there are also some important benefits. Remote working is a money saver because no offices should be rented or bought. Remote businesses can also recruit talent from all over the globe.

What I also see happening with remote-first companies is that group retreats are organized (often to some idyllic place) to boost team spirit. This is a fun way for employees to get to know other employees better on a personal level and to create great memories together.

Conclusion

Scaling a company’s headcount rapidly is possible using “The Company Model“ presented by Lemonade. It is an extension of “The Spotify Model”. “The Company Model“ consists of different “Companies”. For each new product, a separate company is introduced. Companies consist of horizontal “Tribes” and “Squads”. These organizational concepts have cascading goals.

Looking at Conway’s Law, “The Company Model” has a communication structure that is optimized for delivering customer value. Companies, Tribes, and Squads deliver value across the value chain. The model also contains horizontal supportive teams, making it easier to incubate new Companies, Tribes, and Squads.

Finally, I’m convinced that this model can also work for a fully remote team using modern tools as long as the right company culture is present.

I am very eager to hear YOUR thoughts:

• How do you feel as an employee or employer about remote work? What works and what doesn’t?

• How are teams organized where you work? Do you recognize the secret ingredients presented in my article?

• What are the main challenges at your (growing) organization?

• Which tools do you use to support remote work or growing teams and what are the benefits?

Leave a comment