• Reality TV Version of Product Development

  • Twenty years ago, sitcoms where the thing to watch. The last 10 years have been all about “reality TV.” I’m not sure how genuinely “real” it all is. There appears to be a general plot line or series of events that make the episodes interesting. They vary in their amount of “scripting”, but they all contain chaos and surprises. But how does all that play into product development?

    Surprises, Chaos and Scripting

    In product development (PD) it’s tempting to prevent all of the surprises and chaos early on by scripting the project. Project managers (PM) want to have it all planned out – how much everything will cost, how long each step will take, and everything else is captured neatly in forms and tables that are easy to share and use as deliverables. There are some practical reasons for this. Consistency between projects is one. All projects of a certain “type” can use modified versions of a previous project’s form. The timeline of a previous project can be used to project timing for the next one. You know all your regulatory requirements will be met, and so on.

    There’s also a very human reason to script-out your project. It reduces anxiety of the unknown. Can you imagine how TV executives felt when they went from buying scripts that they got to read themselves before putting a show on the air to a situation where a producer says, “I need a million dollars to shoot this reality TV episode. I have no idea what will come of it. We’ll just record whatever happens then edit it right before it airs. I promise it will be great.” That was a risk but look how it turned out!

    Facing Unknown-Unknowns

    On the other hand, there are downsides to scripting projects. It requires a significant amount of administrative people-power. Usually this means that instead of spending the available time developing a technology for a project the PM or engineering team is filling out forms and following up on other people filling out forms that he or she depends on. Another downside is the potential for rework of all the administrative tasks. In product development there are many “unknown-unknowns”. These are things you can’t prepare for or correct because there is no way of knowing they will ever be a problem. Remember when you made some tiny change to a part that shouldn’t have affected anything then then it unexpectedly failed every validation it had always passed before? In that situation you were facing unknown-unknowns. Every new PD project has them.

    Lean-out Your Product Development Process

    Here are some principles to help reduce those scripting downsides and lean-out your product development process:

    Tech-heavy early and fade into admin-heavy later on

    Administrative work must be done, but it doesn’t need to be done quite as heavily on the frontend of the project as the backend. In the beginning focus on the development of the technology of the solution. It is critical to capture all of the inputs, conversations and discoveries along the way, but there need be no formal method of doing so, so long as all the information is collected. Then, gradually as the project moves forward successfully convert the useful information you collected with ease into administrative outputs.

    Embrace the chaos

    If you can accept and be comfortable with the fact that you don’t know how things are going to go you can be better prepared for that in your workload and mentally. More than just accepting it but embracing it will allow you the flexibility to notice and explore alternative solutions.

    Be mindful of the “momentum of the project”

    Projects are slow to get moving and easy to stop. Once a project has been put on hold by either declaring it so or slowing down because there’s a delay in some administrative task team members and stakeholders get distracted, disinterested, and move on. By not overloading resources and reducing the risk of administrative hold-up you’ll keep a project moving in a forward direction and everyone engaged.

    Scale your timing to the target’s distance

    To plan for the chaos don’t set ridged schedules more than two or three weeks out in the beginning. Milestones are acceptable provided the units are reasonable. For a milestone you estimate to be four months out pick a target month. For a milestone a year or more out, set a target quarter. By scaling your target to how far away it is you’ll be able to increase your odds of success which is a confidence boosting event that will keep the momentum of the project strong.

    Product development is more like reality than a sitcom in that one won’t script-in a surprise or plot twist – such things just happen. So, don’t waste time early on in a project with lots of administrative work. Just focus on the tech, embrace the chaos, and keep your team excited and engaged by keeping the project in a forward motion.