Don't tell my dev team's but today is the first day I've felt like I could catch my breath since taking on the challenge of building up a Program Manager foundation at Telligent. That means that it's a good time to talk about what I've been working on as a way of looking back and thinking about improvements.
The product team at Telligent, like most tech shops, is developer centric. This means that for the longest time the developer team has been "self PMing". So the challenge to me has been figuring out what being a PM at Telligent means. Classically, one of the best explanations of the ideal PM role you'll find on the Internet was written by Steven Sinofsky; who now leads the Windows and Windows Live groups at Microsoft.
http://blogs.msdn.com/techtalk/archive/2005/12/16/504872.aspx
...it is PMs that can bring together a team and rally them around a new idea and bring it to market (like OneNote, InfoPath). It is PMs that can tackle a business problem and work with marketing and sales to really solve a big customer issue with unique and innovative software (like SharePoint Portal Server). It is PMs that can take a technology like XML or graphics and turn it into an end-user feature benefitting 400 million people (Office Open XML format or the new graphics functionality in Office12). I could go on and paint a very emotional picture, but let's spend some time digging into the more analytical aspects of the job.
Where developers were focused on code, architecture, performance, and engineering, the PM would focus on the big picture of "what are we trying to do" and on the details of the user experience, the feature set, the way the product will get used. In fact the job has matured significantly and it is almost impossible to document a complete list of the responsibilities of program management...
Steven goes onto explain, with more specific examples, what a PM does. So what does a PM at Telligent do? First let's look at the goals and assumptions that we've made while building out the foundations of a PM team... that's now at 2 people. :-)
- Maintain a high dev to PM ratio. Today we're targeting 1 PM to every 5 developers. The idea being that it's easier to add than subtract later & that we hire developers that have been PMing the product themselves for a while anyway. We should continue hiring developers that can be their own PM's, make smart decisions, and not require 60 page documents that define small features.
- Leverage Agile Development. The developer team was already leaning towards this, but we're now developing our products with multiple 2-week iterations. At the end of each of the two weeks we aim to show completed or enhanced user stories.
- Create lightweight specifications that focus on solving business problems/customer scenarios and add details on demand 1 iteration ahead of planned development.
- PM's are paired with dev leads that manage work item scheduling, dev guidelines, and the developers on the team.
Going deeper into the category of feature development work the life of a feature looks like this:
- Application Level Scenarios defined and ideally roadmapped out over multiple releases. This is the longer explanation that explains something at the level of "Here is how the wiki works for an organization in V1, V2, & V3." Now, what's actually done in V2 & V3 might change, but it's important to be forward looking. You might find something you think could be further out is game changing enough to get pulled into the first version.
- Conceptual's Created. Words are great, but nothing communicates what something does to other people better than seeing it. If you can't prototype then at least wireframe in your PM tool of choice.
- User Stories Defined. At this stage you are extracting micro-scenarios that map to a user with a goal and define the user's exact path through the application to accomplish thier goal.
- Featured Identified. While developing user stories you'll find gaps in your existing application that need to be made up with specific features. Features, or feature enhancements, are required to implement the user stories. Features, as identified, should have enough description to enable rough costing.
- Prioritize with stakeholders at the user story level.
- Detail features as required by developers. This could be a more specific comp with behavior declared. But the goal is to give the development team enough information to build the feature. Any assumptions you've made about the feature should be defined at this point. Ideally this happens as close to real time as development occurs so that if prioritization changes you aren't detailing features or enhancements that don't get used.
- Development. J. Allard gave a presentation at Microsoft about being a PM that said "If people aren't coming to you with questions or as an expert on your area then you aren't doing your job". At this phase, while working ahead of developers for the next set of iterations, the PM is there to answre questions and provide the first pass of feedback on daily progress when things are completed.
- Demo at the user story of the completed features at the end of the iteration. This also serves as your chance to provide more feedback now that you are essentially running a test pass (not real testing yet) to validate the user stories that were defined. We're literally using Jing to create screencasts of new work to send around the company every two weeks.
- Collect feedback from demos and push that feedback into future iterations... refine, rinse, repeat.
There have certainly been some bumps in the road along the way and we're still working on evolving the process, but when it comes to the basic process we're probably within 70% of where we need to be to start more aggressively scaling the product development side of things.
The next 30% will take longer to work out as we perfect what's the idea user story, feature description, iteration length, demo size, etc. Of course there is a lot more work to do than I've described here that involves driving dogfooding, improving our documentation story, figuring out integration scenarios with other platforms & services, etc. But I'll save those for another post.
BTW - if this sounds exciting to you and you have a passion for technology and social software then drop me a line and your resume. We're always looking for good PM's and Developers!
Posted to Design
and tagged as
telligent
,
pm
,
scrum
,
specing
Similar Posts
- Are You Ready for Smarter Spenders Bursting Your Bubble?
- OCS 2007 Breakout - Social Media
- OCS 2007 - On Crowdsourcing
