I tended to the life sciences more than the physical ones when I was in school, but I certainly remember Newton's first law of motion-- an object in motion stays in motion with the same speed and in the same direction unless acted upon by an unbalanced force. As I work with companies big and small, I think about this law often. Momentum is a crucial component of product development and without it, you won’t get to market at the optimal time, you won’t retain talent, and you won’t get the best out of your team. We all know there are many external factors that can cause the momentum of a project to slow. Unanticipated competitive activity, loss of team talent, unexpected market conditions that prevent the flow of resources, changes to corporate strategy—these are some of the unbalanced forces that can throw a wrench into the momentum of a project. As a member of the development team, your job is to be on the lookout for the unbalanced forces and swat them away like Wonder Woman deflecting a blaze of bullets. But what happens when the unbalanced force is coming from within the house (sorry to mix my science knowledge and B-horror movie analogies)? Are you a momentum killer? And what can you do when you encounter one?
The Schedule Killer: These folks are really, really, really busy. They need to provide their buy-in for the project to move forward, but their time is extremely limited. You need to work through an assistant to get time booked. And when you do get that coveted slot, there is a good chance that they haven’t read those last three reports you sent so the time you finally get with them is filled with “catching up” and “What about if you just…..”
If you are one: This is the most common of momentum-busters and the hardest one for your teams to handle because you, the Schedule Killer, are probably the boss. Understanding you have a problem is the first step: it is good if you can see yourself as the hold-up your team does. Secondly, you must trust. Thirdly, you must empower. One strategy I use is a pretty simple question “If you know that I will say ‘yes’, just go ahead and do it.” It won’t take care of all of the issues, but if this works 30% of the time, that is 30% fewer meetings your team has to schedule. It will improve momentum. And morale. The only way that works, however, is if you have shared enough of your core values and outcomes with the team so that they can make these decisions as you would.
If you encounter one: Scheduler Killers respond to deadlines. Instead of asking when they are available to talk or asking them what they need to know, start with the schedule. “We need to make a decision on which vendor will be building the assessment items by Friday to meet our market launch. I have included three proposals and a cover sheet with my recommendations. I am available Tuesday, Wednesday and Thursday to meet in person or on the phone to answer any questions. Will you need anything else to make a decision by Friday and keep us on track?”
The Techno-Killer: What I have learned about tech leads are that they are smart and more than willing to imagine even better ways of doing things for the customer. But their lack of understanding of real, authentic customer workflow, and how and when those customers interface with your product can be a real distraction, especially when building an MVP. I have found that for many tech leads, there is an imagined customer—one that is often way more enamored with the product than a real customer would ever be. So what starts as a product improvement can easily result in additional scrums and sprints that lead to over-engineered features that aren’t core for MVP releases.
If you are one: The difference between a requirement and an outcome is in the eye of the beholder. A product requirement might read “functional grade book that allows for customization.” However, from the customer side, they are looking for an outcome: I want to easily see how my students are progressing and transfer the grades I need into my LMS. The first will require lots and lots of work—the second could take a whole lot less—especially during the MVP phase. Making sure you understand the outcome desired, not just the requirement, will eliminate spending time over-thinking and over-producing something that is not core to the value proposition.
If you encounter one: Help your tech lead see the requirements as outcomes. Challenge them to think about the requirements with some different values: these requirements are business as usual and we know how to do them-these requirements are the “secret sauce” and the outcome of what they do will be the main selling feature—these requirements are nice to have ONLY if we can figure out a creative, fast, and cheap way of getting them done. This will focus their energies on where it will make the biggest difference and help them avoid getting sidetracked by several different features.
The biggest issue in killing momentum is wasted time. In today’s offices I often hear we are “building the airplane as we are flying it,” but it isn’t usually because they are deftly agile: It is usually because earlier in the process, some momentum killer tied up valuable time--time that could have been used to micro-test the product with customers, improve the product, and reduce issues during the Go-To-Market stage. Because sometime momentum killers kill more than momentum.