Eating your own dog food

There's an odd term in the software industry called "eating your own dog food."

Microsoft coined this term in the late 80s.

The main idea is that companies that make a product should use that product on a daily basis. That way, you can experience the pleasure (or pain) yourself, and have a better idea of where to focus resources.

At PMRobot, we use our own software every day.

It was conceived and born in our sister company, Syllogistic Software, and continues a core element of our processes.

"Dogfooding," as its often referred to, is absolutely essential when building a product, because it really helps motivate internal innovation, and quick fixes to problems.

A similar example, dating all the way back to 1981, is when Apple decreed in a memo:

“EFFECTIVE IMMEDIATELY!! NO MORE TYPEWRITERS ARE TO BE PURCHASED, LEASED, etc., etc. Apple is an innovative company. We must believe and lead in all areas. If word processing is so neat, then let's all use it! Goal: by 1-1-81, NO typewriters at Apple... We believe the typewriter is obsolete. Let's prove it inside before we try and convince our customers.” - An Apple On Every Desk

If an annoying change makes it to the server, we experience the pain first hand, instead of just hearing a second hand account from our customers.

If you develop a product, consider making daily use of that product a habit.

I guarantee it will help you produce something of much higher quality.

You can't assign 1 task to 2 people

This is one of my biggest pet peeves with certain project management software packages out there.

You cannot assign one task to more than one person!

And yet there is tons of project management software out there that lets people adopt this bad practice. Have you ever tried asking a group a question? It just leads to individuals assuming that someone else will take care of it.

You: "Hey team, Is the release going to be ready for Friday?"

Developer: "Well, I've done everything I can, but the client hasn't sent their logo yet."

QA Person: "The file interface is still buggy, but I'm not sure if I'm supposed to log bugs about that yet."

What's wrong here? There's no clear responsibility and no one owns the task.

Responsibility is key to all projects, and every task needs one person to be ultimately responsible for moving it forward.

This does not mean that multiple people can't collaborate and contribute towards the solution, but multiple assignment is often very dangerous.

Instead of both people taking responsibility, each one assumes the other one has it covered, and nobody takes any action.

This is why in most companies, there is a single CFO who is ultimately responsible for the finances or a COO who takes ownership of sales and operations. They would not be able to succeed without support from their teams and colleagues, but at the end of the day, they are responsible.

From the very beginnings of PMRobot, when it was just a simple ticketing system, we designed it to ensure that a ticket could only be assigned to one person at any given time.

This leaves no chance for ambiguity or misunderstanding about who needs to get what done.

If you want to increase your efficiency and reduce the number of things falling through the cracks, make sure you only assign things to one person.