Name: Jack Lyon
Role Title: Product Manager
Tours of Duty: CNET, Blurb, GOOD
How would you describe what you do?
As stereotypical as it sounds, my main job is to keep new development moving forward fast. I make sure projects are clearly defined, that there are no major roadblocks and everything is on schedule. Part creative thinker, part project manager, part QA engineer, part production manager, part team advocate, etc.
Aside from a 10 minute daily stand up, there are typically at least four meetings required through the course of an entire project or sprint:
- Kick-off:
Get all the stakeholders in a room and discuss what the project is, its major feature set, the main goals, and the timeframe desired. This is usually the most difficult, as everyone wants their “million dollar idea” included and the core idea of the project can quickly morph into something completely different as people start scribbling wildly on the whiteboard. - Requirements Review:
Ideally, this should be a brief meeting as the basic feature-set has already been agreed on. This is usually just a bulleted list and possibly a wireframe or two. - Design Comp Review:
Check out the final comps, make sure all the stakeholders are in agreement and that all the major features are represented. This can also get quickly get tricky as everyone has an opinion. - Release Candidate:
The feature or site has been built and is ready for testing. This is basically a demo that the engineers give to QA and the key stakeholders.
But this process rarely works, as many requirements, designs and test candidates never make it through the first review. So you end up having Meetings #2 through #4 over and over again. Many companies do this and still think they’re agile, but it’s still a fundamentally waterfall process. Just because you create requirements as user stories doesn’t mean you’re an agile shop. Writing a phone book-sized product requirements document vs. breaking the same, stiff requirements into 1,000 separate user stories doesn’t change the process.
If you’re a truly agile and small team (either a start-up, or an autonomous group at a larger company), all the work behind Meetings #2 through #4 all happen at the same time. Requirements morph, and designs tweak around different code implementations as the team discovers what works and what doesn’t.
And that’s what I try to make happen every day. Collaboration throughout the dev team and stakeholders, while making sure we’re always building what we first meant to and not falling into the realm of feature bloat.
…Watch for Part II of our interview with Jack!