Getting Above the Fog

There are basically three areas of concern in product development:

1. Business
2. Users
3. Technology

The trick is understanding how the three coincide. In the day-to-day process of developing products it’s easy to become myopic and focus on just one or two of these areas. It’s really hard to get above the fray and see how they overlap and complement one another.

As we work on our product, we have to deal with many different voices advocating for each area, listen to their concerns, and be diplomatic while making difficult decisions. At times, it’s like we’re groping in the fog.

How do we get above it all to see the bigger picture and make better decisions? How do we avoid going off on tangents and trying to solve every “huge problem” that comes across our radar?

Recognize the distinctions

There are three distinct areas of concern

First, we must acknowledge that there are three distinct areas of concern. Each area has its own set of problems and goals, and, most importantly, each is the authority on what those problems and goals really are.

In other words, the business cannot dictate what users are trying to do or what they need. Beware if your product is purely based on stakeholders’ assumptions about what the market needs. That said, stakeholders are the absolute authority on what the business needs! Let’s not ignore that. They know the mechanics of their chosen business model and should be able to tell us exactly what’s required to sustain the business we’re all operating within.

Likewise, users are the absolute authority on their problems and goals. It’s tempting to impose our ideas on the market and be led by our assumptions about what people need. Talking to the people whose problem we are trying to solve is fundamental to arriving at the right solution. Watching them work and hearing them express their intentions and goals is incredibly telling. It’s so much more gratifying than sitting in our office, building things based purely on assumptions, and crossing our fingers hoping we helped someone, somewhere accomplish something they care about.

Those who work closely with technology know the ins-and-outs of building a scalable system, the problems they need to solve, and the goals they want to achieve. They are the absolute authority on those things.

Business. Users. Technology. Respecting each area as its own authority and recognizing that they each have different problems and goals will give us the right perspective to move to the next step.

Find the overlap

The three areas overlap where there are shared concerns

Now that we’ve looked at how the three areas are different and independently authoritative (as far as their problems and goals go), we can start to look at how they are the same. There are a host of questions to help us determine the overlap.

• If the business values [this], what user activities might be instrumental in generating that value?
• If [these people] are trying to do [these things] would helping them do those things benefit the business?
• Which technologies would enable [these people] to do [these things]?

There are many ways to slice this, but you get the point. We’re actively looking for the overlap, striving to connect the dots between all three areas. In real life this is much harder than the diagram above betrays, but it’s entirely possible if we’re persistent enough! We can talk to business stakeholders, users, and our technical colleagues. All of the information is available to us if we would only reach out and get it.

In my experience, this process literally feels like a thick blanket of fog gradually lifting. Everything is fuzzy and indistinct at first, but with much concentrated thought and effort, it eventually comes into focus.

Determine the boundaries

The intersection of all three areas describes the boundaries of your problem space

Now that we have a whole new degree of clarity around each of the three areas, recognizing their distinctions as well as their overlap, it’s time to determine the boundaries of our problem space, i.e. the problems (and goals) that our product will address and those it won’t.

The last thing anyone wants is to build:

• A technically sound product with a solid business model but low market appeal
• A technically sound product with high market appeal but an unsustainable business model
• A product with a solid business model and high market appeal but technically fragile

All of these scenarios are avoidable if we gain clarity in these three areas up front and keep that focus throughout the development process.

We want to be able to fill in the blanks below. If we can, that means we have some serious clarity.

This product/feature leverages [these technologies] to enable [these people] to do [these activities] that — directly or indirectly — generate [this business value].

This article isn’t about designing solutions. It’s about getting above the dense fog of problems and goals that everyone seems to have, and achieving clarity around our product well before we get into solution mode.

How have you achieved clarity in these areas with your team?