Software: Producing Less Can Equal Accomplishing More
Building a software product well takes an amazing combination of talents from a team of skilled individuals. When you have a passionate group of engineers who want to put out a product they can be proud of, as a product manager you often find yourself doing something you never thought you would do: scaling back the scope of projects.
The stereotypical interaction between a PM (product manager) and a development team is that the PM asks for the world, and the development team argues that they can only give him a city, or even a town.
Just recently I realized that, as a PM, I’ve started encountering the opposite scenario — I ask for a town and my team wants to give me the world. This has been a surprising role reversal, to say the least, but it’s also one that I’ve found is a dangerous one and one to be very wary about.
Go Small
As a product manager, my team has started giving me a hard time because I constantly find myself shaving requirements from stories. My goal is always to get the smallest increment possible completed and delivered, so we can measure the results of that change and then rapidly iterate on it. The smaller the iteration, the more rapidly you can iterate on it, and I love getting feedback that can be turned into actionable change.
A typical interaction on a team demonstrating this would look something like this:
Tom, a PM for a product comes to the table asking for a new way to inform users that an update has been pushed to their product. He defines the acceptance criteria for that story and gives it to the team. While the team is working on it, Nicole, a talented software developer on the team completes the work in no time at all and then comes up with an additional enhancement she thinks would be awesome to add to the feature. Tom considers the request, sees that it does have value, but wants to push that into the next iteration on this feature. Reluctantly, Nicole agrees and they push out a small update that allows Tom to do exactly what he asked for in a very simple way. It’s not the sexiest thing in the world, but it gets the job done.
The interaction between Tom and Nicole in our example above is the important one here; sometimes, the team wants to do more.
This hinges on a few very important concepts though, or it will not work.
First — Make change that you are confident will have an effect.
Change should be driven by a need and result in a measurable outcome. If you release a new product, but it does not result in an increase in use, revenue, or customer satisfaction and does not decrease the number of bugs, support requests, or customer complaints, then you have wasted time. On the other hand, if you change the color of a button and it results in more interactions with your primarily workflow, you’ve got a huge win.
Make the smallest change possible that you are confident will have the desired outcome. Do not sacrifice outcome unless you know that you will need several iterations to get there, but also do not lose sight of the outcome you are trying to achieve. Anything ancillary to that outcome is a distraction and should be pushed off or dumped altogether.
Second — Give your team confidence you will give time to iterate
Why would Nicole, in our above example, hesitate to make a smaller change, not a larger one? When working with really good, passionate individuals, for them it’s more about doing work that they can be proud of, rather than just getting the job done. The fear you will find is that your team doesn’t trust you as a PM to give them time to come back to the half-baked (in their opinion) feature and improve on it. So you need to do two things to win their trust:
- You need to have the business understanding of your market to be able to explain how the small change you are putting out has value. If it really does have value, then your team should not object to a small change. If you cannot sell this business value to your own team, it’s a good sign the value you propose does not exist.
- Iterate. A lot. After you put that small change out immediately have some follow up work to improve on that change. This gives the benefits of allowing you to rapidly get an actionable change out, but also gives your team confidence that you’ll give them the time they want to make it something awesome.
Skip Unnecessary Iterations
One of my favorite experiences lately revolves around a huge revamp we did to one of our product workflows. We had done our user research, developed the first iteration of stories around it, and released it to our users with training and communications around it. We were just about to start on the second iteration of changes for this feature when my product designer came to me and said something totally unexpected:
Hey, you know those follow up stories for this? I don’t think we need them.
He had performed some follow up research with our users and found that the new workflow we had put out solved 90% of their problems with the original functionality, and they did not want or need anything else, for now. To me, that was great news, I was able to push those stories out and get other value-added items moved up instead. We could have rolled those additional items into our original release of the workflow, but if we had we would have:
- Taken longer to release the feature
- Increased the risk of introducing bugs or disrupting current functionality
- Built something that wasn’t needed
That last bullet is the most important one. We were able to avoid building something our users did not want or need, and instead work on something they did need. That’s a huge value-add.
The typical interaction between a PM and a dev team is the push and pull of more or less. But this dynamic is not always the PM asking for more and the team pushing for less. If you have a passionate team, you may find that they push to do more, when all you need is less. Make sure that you build the trust with your team necessary to show how valuable small changes can be, and how you may avoid wasting time in the future by doing less now.
