I have spent five different software engineering internships with four different companies, ranging from SF startup to the biggest of big tech to German auto manufacturing. Each of these companies employed their own styles for product strategy and team updates, some were very intentional others were less so. In User Story Mapping by Jeff Patton and Peter Economy, the authors reference the agile methodology of software development quite frequently in their introductory chapter, but without even feeling a need to explain this framework, they jump straight into proposing their story mapping method. Nothing I have seen in industry has been remotely close to this approach, and this is to the detriment of my teams.
The user story mapping methodology employs a couple useful action items to roadmap a product or task in a fundamental and approachable way. The authors speak at length about how documentation and requirements are not the pinnacle of good information relaying and strategizing. Rather, communication itself should be the groundwork for information relaying. To them, this takes the form of a personal conversation where ideas are written down on index cards or sticky notes. Then whenever the idea is again referenced in the conversation, all parties are able to recall the main points with the help of this visual cue. At the end of the conversation, these index cards can be organized and reorganized, prioritized and reprioritized until a solid, visual gameplan lies directly in front of everyone. Now there is little chance for misunderstanding or oversight.
My experiences have been quite different. With the exception of the Hacking for Defense class I took with Steve Blank two years ago, I have seen little of true needs-based prioritization and iteration in industry. At my startup job, my boss and I were the only in-house engineers, and we had full rein over our app for fire brigade management. It was like flying a beautiful prop plane over silky white clouds into the deepest blue skies–with no clue where to land. At my international corporation, I interfaced with my team at large maybe a handful of times throughout the three months. The rest was just the occasional catch up with my boss and doing what he wanted me to do that week. Within big tech, there were weekly team meetings, mentor meetings, and partner meetings. There were meetings upon meetings. Much was discussed, much was demoed, but nowhere did I find strategic thinking. We were the marine 0311 infantrymen whose job was to execute and not ask questions. Features would be deployed, and A/B testing would then be used. I felt as if my purpose was simply to prevent other companies from having my “talent”. Of these strategies the first provided the most motivation on my end, but the least results. The last strategy sucked the life from me, but eked out some earnings in the end. In the end, no team felt that they had complete ownership, understanding, or a single story from a user.
