Product Management Lesson 3: Following Process
Note: While my employer strongly influences my thought process in this area, the content presented in this post and others do not directly reflect the views of my employer.
There is always a fine line between too little process versus too much process. As a product manager, while you are not solely responsible for all of the processes in place, you are ultimately responsible for the product that is delivered.
Since processes help deliver product, then by default you should have some level of ownership in how the working team sets up its processes for building/shipping/measuring product.
One lesson I learned from our recent revamp of the Mint app, is that the most tempting time(s) to break process is exactly when your team needs it the most.
Processes often require increased work in the short term, but can save exponential amounts of time and energy in the long run. When your team is working to deliver a project on a short timeline, it is easy to lose sight of these long-term benefits. I fell into this trap at times with the Mint revamp.
Processes often require increased work in the short term, but can save exponential amounts of time and energy in the long run.
When the project first kicked off, I knew we had a very short amount of time to get the project off the ground or risk losing the trust of leadership. As a result, I allowed our team to cut some corners in our process in exchange for speed.
In the short-term, the reduction in process paid off. We were able to hit critical milestones and were pushing product experiments & features faster than any other team across Intuit. I knew that our lack of process couldn’t continue indefinitely, but the longer the team went without rigorous process in certain areas, the more difficult it became to change things.
In the few months from concept to launch, we had to have a number of difficult meetings to handle misses by the team. At the heart of each of these meetings was an issue that could have been solved with a more rigorous process in place.
Luckily for our team, none of these mistakes were mission critical and we were able to course-correct and still hit our deliverables. However, I learned some hard lessons along the way.
If there is one thing I would have done differently during the Mint revamp, it would have been to implement more rigorous processes from the beginning. While these processes may have been met with resistance initially, they would have saved our team some major headaches down the road.
