A Software Engineer's Guide to Building Better Products

Bob was a solution-space engineer. Henry was a problem-space engineer. Bob worked at the world's first shovel company, and coincidentally he engineered shovels. They were beautiful shovels, and worked really well. Henry worked at the world's second shovel company, but they never really thought of themselves as a shovel company. They thought of themselves as a company that helped people dig holes. While Bob was perfecting the shovel, Henry engineered an excavator. Henry was a problem-space engineer.

---

Jobs-to-be-Done(JTBD) Principles

This article is an attempt to describe how the JTBD methodology can be applied as a software engineer. It will help you create more value for your organization (and more value for your pocketbook). To fully understand how these principles can be applied, a brief overview of JTBD is required. Customers buy products and services that help them get jobs done. That's it. If you would like a much more detailed explanation of these concepts, you can check out outcome-driven innovation and jobs-to-be-done.

Why Should I Care as a Software Engineer?

It doesn't make an ounce of difference whether you are a soloprenuer, an owner of a large software development organization, or a software engineer employed at an organization of any size. You provide a service or product that helps somebody get a job done (if that's not the case, then you probably shouldn't be employed). However, many software engineers have yet to come to this realization.

They think they provide the most value by knowing Ruby, Java, Angular, C++, or WhizBangFrameworkX, etc. They are continually looking to improve their technical skills (a good idea, actually). They constantly seek to implement new technologies, and will find any excuses to use them within an existing software platform. They know and understand the ins-and-outs of a diverse set of technologies. They can implement solutions to many different types of problems. They are certainly valuable in their own way, and there is a significant demand for this type of talent. However, many of them are missing significant opportunity, primarily due to their reluctance to move from the solution space to the problem space.

What is the Solution Space?

The solution space is the place where solutions are implemented. The following points are indicators that a software engineer is living in the solution space.

• They turn detailed requirements (either via extensive documentation or with significant input from a business partner) into working features.
• They continually require significant technical guidance.
• They build features within a well established technical architecture and framework.
• They think of the customer as those annoying people who always have trouble using the software.

What's the problem with this? Nothing really, for those software engineers who don't mind being a commoditized resource. Unfortunately, even for those developers who can crank out features at an incredible pace, they will always be viewed as an easily replaceable warm body.

What is the Problem Space?

The problem space is the place where solutions are formulated. The following points are indicators that a software engineer is living in the problem space.

• They are continually injecting themselves into business conversations and provide valuable business input.
• They don't just implement features, they suggest new ones, and provide input on how existing ones can be improved.
• They are often recognized by many departments within their organization. They've injected themselves into so many meaningful conversations, that it is not uncommon to find them providing support to the sales team, the marketing team, the maintenance team, etc.
• They have an uncontrollable desire to fix problems (even if they're not a technology problems).
• They understand what job the customer is trying to do, and all development is done within that context.

So what's the key difference between the solution-space engineer and the problem-space engineer? Outside of their department, the solution-space engineer is just known as 'that developer.' For a solution-space engineer who has managed to endure a period of longevity, some of the business folks may even recognize their first name, and call out greetings as they pass in the hallway.

However, the problem-space engineer is in a whole different realm. Their opinions are sought out by both the technical and business people. They are included in key meetings, and their absence from these meetings is noticed. They have the ability to think like the customer, and fully understand what job the customer is trying to accomplish.

Why Doesn't Your Organization Reward You for 'Doing Your Job'

I've had numerous recurring conversations over a period of years that have followed a similar theme. Bob, the solution-space engineer (and Bob isn't always a software engineer - but Bob always lives in the solution space), laments to me that the organization doesn't seem to put much value in just 'doing your job.' Or that good annual performance evaluations require developers to work on a number of 'special projects' that weren't part of their daily job. Or that somebody got a promotion who didn't deserve one.

There's been time when I've been Bob, the solution-space engineer, and was initiating these conversations. However, I eventually came to the realization that these conversations stem from one of two reason.

• Ignorance - Bob simply doesn't understand the important distinction between a solution-space engineer and problem-space engineer.
• Personal responsibility - Bob isn't willing to inject himself into the problem-space conversations. This may be due to lack of initiative, fear (you have to put yourself out there to be in the problem space), or an unwillingness to take on more responsibility.

How Can You Move Into the Problem Space?

If you happen to be a software developer who lives in the solution space, and would like to move into the problem space, all is not lost. Making the transition is not that difficult. It just takes a bit of effort and initiative to make it happen, along with a systematic application of the JTBD methodology.

You have to start looking beyond just the tasks that you've been instructed to do. Each task you complete is part of a more meaningful job that is being done within your organization. You need to start thinking about what those big picture jobs are, and then start creating ways to do that job better. Additionally, you need to continually be injecting yourself into those conversations in meaningful ways.

• Awareness - You need start making yourself aware of what jobs are being done within your organization. This means that you know how your software creates value for your customers. This means that you understand what jobs are being done within your organization (not just the job of creating valueable software).
• Notice Friction - What things do you find frustrating about your job? Anytime you encounter friction while doing your job, you've entered the problem space.
• Find a Solution - Noticing problems isn't going to be enough to get you noticed as a problem-space engineer. To achieve that status and level of recognition, you have to find solutions to problems you've discovered.
• Automate Your Solution - automate your solution so that it never bothers anyone again. But remember to make sure key leaders are aware of the accomplishment. Failure to make the right people aware of the solution will guarantee that you will never receive credit.
• Evangelize Your Solution - If your solution is not something that can be automated, then you'll need to put on your evangalist hat. Failure to alert your organization of the solution to a problem isn't dramatically different than not solving it at all. Many solutions require mobilizing the workforce to implement the solution. Failure to do so will inhibit your ability to get recognized as a problem-solver. Need some hints on how to mobilize the workforce? See this article.
• Inject yourself into problem-space conversations - when you hear of conversations about problems in your organization, add your input. While you don't always need to provide the solution, it does help if your input adds value. Making noise just for the sake of being in the conversation is distracting and counter-productive.
• Understand the Business Domain - So many engineers fail to realize the importance of understanding the business domain. They'll spend immense effort perfecting their technical skills, yet they have no clue how their customers use their products. This disregard for what the customer is trying to accomplish has accounted for significant software bugs and poorly designed products.

Solve Problems that Matter

If you want to get the most leverage out of your problem-solving abilities, you'll have to work on problems that matter. This means solving problems that have significant business impact. Issues with insignicant business impact (even if they create significant annoyance when encountered) will garner very little recognition. However, solving big problems will create wide organizational recognition, and you will gain instant credibility as a problem-space engineer.

Summary

By understanding what jobs your customers (internal and external) are trying to accomplish, you can move from the solution space into the problem space. When you start taking part in the conversation, and adding value beyond just cranking out features, you will no longer be just another operational expenditure on the income statement. You will become a real person who adds real value to real business conversations about real business problems. Coincidentally, when you achieve this status, your pay will no longer need to be determined by the going commodity rate on the market (think big pay raise).

Related Posts