Solving problems

I self identify as a “problem solver”. For many people, “problem solving” is a phrase used to describe being decisive or getting actively involved with the details of improving sales, operations or any other part of the business.

My experience is that true “problem solving” happens before taking action. First you need to make sure you really understand what the problem is.

This is something that is very easy to forget during a typical day.

Usually what we do is focus on key details that form a pattern (or “frame”) and use that frame to get through the day. Something like “as long as we make our revenue numbers everything will be fine” or “minimize engineering time needed for your project because there is never enough available”. It’s a very effective way to process the vast amounts of information we all must cope with and it’s also often responsible for our mistakes.

We’ve all met or worked with people who fixate on worst-case scenarios, are overconfident and overlook possible scenarios or let past events leave an impression that colors everything they do. These are examples of how a single frame can lead us down the wrong path.

They also show why having multiple frames to look at your problem are so useful. Here is an example of how I typically approach helping web sites earn more revenue. It’s like an audit designed to flush out what’s really wrong:

1. Page performance. How fast do web pages load? What parts of the page take longest to load and why? How do pages “perform” relative to content on similar web sites?

2. Design. What are the different templates used to publish content? How does the design of each template drive visitor behavior?

3. Navigation. How do different pages connect to each other to create a typical user experience?

4. Visitors. Who are the site “personas“? Why are they viewing content? Where are they coming from? What problem is the web site or landing page trying to solve for them? What else is known about them?

5. Reporting. How and when are key performance metrics collected, reviewed and shared?

6. Operations. What is the actual process for designing and publishing web pages? How are ad tags tested and deployed?

7. Staff. Who handles sales, operations and other parts of the business? What is their experience and training?

8. Documentation. What gets written down for the purpose of sharing or preserving knowledge? Who uses it? How often is it updated?

9. Revenue. Where does revenue come from? How evenly is it distributed across different sources?

This approach can seem complicated. It isn’t. It’s merely a way to apply the same sort of thinking described in the famous parable of the kitchen spindle to typical problems encountered in operating web sites – i.e. Looking at how different kinds of “frames” (expertise) would “describe” the problem.

It’s also a great way to truly test your understanding of what’s wrong or what must be done well as opposed to good enough. And while I specifically referred to operating a web site in the example above, it’s a way of thinking that’s useful for solving any kind of problem.