Are you ready to shift from being a passive observer, a notes taker, a meeting scheduler to an active architect of your TPM career success? Then keep reading….
If you are a Software TPM / TPgM a lack of Technical Understanding will hinder your reputation, influence, communication and decision-making.
Technical understanding is not about
Knowing Java, C++, Python or the next networking protocol or cloud APIs.
Knowing how to review CLs.
Knowing how to do a detailed design.
Knowing how to write unit test cases.
Technical understanding is all about
Knowing in depth the functional requirements. Step into the shoes of the customer, and see if the requirements make sense. Are the MVP requirements really MVP?
Knowing in depth the UX flow (if applicable) or what the APIs do (if its a platform or a service).
Knowing in depth the big boxes and flow of information. At the end of the day software is all about “creating an object”, “modifying the object” and getting or setting the object.
Knowing in depth the dependencies between various modules.
Knowing in depth what is changing and why and how it impacts the project or the end user.
How do you build the technical understanding and how does it help?
At the beginning of the project:
Be a part of PRD/UX creation. Don’t just be a meeting scheduler or wait for these documents to be created. Collaborate
Read the PRD, UX flows multiple times. Add your feedback, opinion, comments. Contribute.
Read the engineering design, ask questions. Try to understand the big building blocks or why things are done in a certain way. Understand the building blocks
Understand the dependencies in code. How many modules/teams are involved and what are their priorities? Identify Dependencies and Risks.
Distill requirements into CUJs (Critical User Journeys). Stack rank them into P0, P1, P2 (there can be multiple P0’s, P1’s etc). Write down delivery plans for each CUJ in a spreadsheet with the owner. Work with the owners for estimates and ETA. Plan
Execute & Improvise in an agile fashion.
During the project
Once active development starts, things evolve. As people design, requirements tweak. As we code, design tweaks. Be on top of what is changing, why and what is the impact on the end user? Watch out for team cutting corners and contributing to a sub-par user experience. Understand the change.
Teamfood and Dogfood: Don’t be afraid to play with the software and provide feedback (in a very constructive way) to your developers or to PM/UX designers. Open bugs with details (screen shots, logs). Be the best dog-fooder.
Run beta programs. Ensure that end user feedback makes it back to the project team on time. Listen to customers, they are always right.
Be an active participant in triage meetings. Remember every bug can not be fixed. Be a triage champion. Maintain a backlog. For bugs that are deferred or closed without a fix, always put the end user impact and why this decision was taken.
Follow these steps for a couple of months and you will see the difference yourself !