Everything as a Product

If you work around technology there’s a good chance you’re around processes that suffer from a lack of product thinking. These are the processes that produce things like “internal tools”, “status reports”, and “meetings”.

The difference between these things and a product your company puts out to market is that the latter is subject to all sorts of scrutiny and care, while the former is often some evolution of, “I don’t know, someone at some point decided something and no one really cared so that’s how things ended up.”

One way to close this gap is to think of all these processes and internal tools as products.

The reason I’m using this loose definition of “product” (as simply “something that solves a problem for someone”) is to invoke all the good stuff that goes along with product thinking. When we think of internal solutions as products we get a ton of good habits for free.

Example: Status Report

Executive says, “Managers need more visibility into the projects IT is working on.” This is a Project Management responsibility so Project Management embraces the problem and comes up with a solution: a weekly email sent to managers every Friday afternoon that provides status updates for the Top IT projects.

Sounds good. The email goes out week after week. You know what happens next. No one actually reads the thing. Now Management is frustrated because they still don’t have visibility into what IT is working on, and IT is frustrated because they gave Management what they wanted and they still aren’t happy.

The problem is that IT didn’t give Management what they wanted—they gave them what they asked for.

What did Management really want? Individual managers wanted to know why their projects were not being executed more quickly. They didn’t care about other people’s projects and they didn’t actually care about “visibility”, which is often a proxy for something else.

It’s No One’s Fault

One of the interesting things about this is that no one did anything wrong. But how might we have gone about it differently?

By realizing that the function of IT communicating project status is itself a type of product.

If we had interpreted the executive’s request as a product idea, the first thing we might have done would have been to grab a designer and have them diagnose the problem.

In the scenario above, a good designer could have identified the real need (which was masked by the request) and then navigated the team to a more effective solution.

Internal Tools Products

An obvious opportunity for this sort of productization is with internal tools. We all know it’s not uncommon for internal tools to be held to lower standards than user-facing products.

Read this excerpt from an Etsy job posting for a product designer on their internal tools team:

One of the most important components in building a successful marketplace is building the internal tools required to allow us to effectively and efficiently give our members the support and features that they need. While our members aren’t always exposed to this side of our work, they definitely benefit from it. On the Internal Tools Team, you'll create products with the same rigor and expectations that go into the rest of the marketplace.

This is great. Why wouldn’t you want to equip your employees with tools that match the “same rigor and expectations” of the products you ship to the marketplace?

Economic realities may prevent us from forming an internal tool product team tomorrow, but it’s likely that there are plenty of small optimizations that can be achieved with the resources we already have.

Maybe you work in technology and some department is looking for project management software? Design the right solution for them. Take the time to discover their specific needs and figure out if they need Google Docs, Trello, Basecamp, or JIRA. There’s a world of difference between these options and getting it wrong will be costly.

Maybe you work for a small publisher and your CMS is a basic install of Drupal? Free up some bandwidth for your best designer and developer and let them run with it. You may be stuck with Drupal but at least it can be your Drupal.

If you’re responsible for internal software that lots of people use, give it a name. Give it a roadmap. Share updates with the team so everyone knows it’s alive.

Increased attention to the real needs of our colleagues can only be a good thing. But the day-to-day dynamics of the workplace don’t make it easy.

That’s where the product trick comes in. By applying a little product thinking to things like internal tools and processes, we can avail ourselves of a familiar framework for building stuff people care about.