As a practicing product manager, it’s quite refreshing to be told that documentation is not everything, particularly because it’s held in such regard in many product management courses or by gurus in the field. In terms of how we compare with how things are suggested by the article, I would say we have one similar trait, and one differing trait.
As modern day early stage tech startup, we’ve adopted a 2-week sprint-style agile workflow. This style entails that we have at least 4 coordination meetings between the product team and the engineering team, as well as a ‘retro’ all-hands meeting to discuss START/STOP/CONTINUE points from last sprint. This cadence was developed to make sure the whole team had a shared understanding, rather than just shared documents. So in the sense of implementing a shared understanding vs a shared documentation, I think my team has done well to use the former principle. However, when it comes to measuring and valuing outcome, they still have a long way to go. The team is structured in a way that there is a ‘scrum master’ working for me, the PM. She does an awesome job at writing the Jira tickets, writing up the user requirements, and ensuring shared understanding with the engineering team. However, she mostly focuses on output rather than outcome and impact. Her methods of ensuring quality is mostly done from a production stand-point rather than a user satisfaction stand-point. I think the best way to help with this is to help her become more engaged with the user side of the business. This way, she can develop more empathy and understanding of what impact and outcome is for the product. I can say that we spend a lot of time either revising product requirements, or even re-doing features because there was a lack of outcomes-focused thinking. Changing this would be a huge time saver.
