Eighteen months ago, I was part of the founding team at a cutting-edge technology start-up. During the first few weeks, as I lined up and conducted dozens of prospect, industry, and expert interviews, the founder hired a talented senior engineering team, and the company was formed. Agile. Mostly by design, but partly because it just worked.

While I didn’t have the challenge of undoing existing processes, since none yet existed, I did still have a learning curve. Becoming Agile doesn’t happen overnight and, like most methodologies, it never looks quite like the definition. After 18 months of being an Agile Product Manager, here are the top five lessons I learned.

Lesson 1

Get a little closer... It’s all about the team.

Our team started by working in the same room in a hosted office space. Because of our very close physical proximity, we had countless interactions daily, working through each piece of the architecture. As we grew, we took over additional space and split into team rooms (Since I was cross-functional, I got stuck with the IT guy who charges me a quarter each time I curse. He just bought a new truck!). In spite of separate offices, we were still meeting face-to-face as a functional team, with a team whiteboard per office, and daily discussions on the next steps were still taking place. Hyper-interaction flowed naturally and work flowed smoothly.

Then we moved into our new, spacious, permanent office, and something strange happened: what had once been absolutely natural interactions now required getting out of our chairs and walking an extra 40 feet, while balancing a coffee cup on our laptops. It was a shock, but we stuck with it, and racked up the numbers on our pedometers.

Sounds obvious, right? But, it only became clear to me that this was working when I realized what I was NOT experiencing in this environment: the “Email Bomb”. For the lucky ones who have not experienced it, here is how the Email Bomb goes:

There is a written requirement (or bug, or request). A team member "attacks" it by sending out an email that aggressively twists the words in ways that are slightly demented.

The incident highlights a personality disorder, and causes a mild amount of chaos. Not only is this a failure in communication up front, but a culture that accepts “communication” via email and downplays the importance of teamwork enables this behavior, and should be at least partially to blame.

Our initial forced proximity made us a stronger team, and we have made it part of our culture to continue this. New team members find it slightly shocking, and outright refreshing that we choose “communicating” rather than emailing or IM, but the net effect is a more effective team, and an amazing culture.

If you can’t directly work with your team, use Skype^® or LifeStyle^® to video conference with them daily. Agile development is all about teamwork, and building on each others strengths (see Lesson 5).

Lesson 2

Even though they wont read your tomes, you still have to write them.

Don’t short-change yourself, write the Market Requirements Document/Product Requirements Document. They provide a strong foundation for an innovative, market-driven product.

One thing I loved about the idea of being Agile was that there was no longer a three month period where I had to create tomes of requirements and specs. I imagined the world where I would type up a single sheet of paper with a requirement and hand it off to the team to build, get a feature back two weeks later, and move forward with the next requirement. Good-bye hand cramps!

I was so wrong! Not only did I still have to write the requirements, but I had less time. This may be because of the newness of my market, along with the fact there were no direct competitors when we started, but the MRD and PRD are the foundation of my ability to define the functionality and use cases for the team (see Lesson 3) and I refer to them far more often now than I ever did. They are continually honed as I moved forward in understanding the market and product, but the foundation is critical to our ability to move forward.

Through the forced group review, the MRD and PRD gave the engineering team context. When the team sat down and started really talking about the overall goals, they had creative ideas on how we could meet multiple, seemingly unrelated, requirements through a single design change. Had I skipped the larger picture documents, and only provided small sets of features to the team for implementation, we would have lost several of these "ah-ha" moments and taken longer to complete the individual features.

Even if they aren’t required, write the MRD and PRD. It doesn’t matter that you are the only one who refers to them after the initial review. It ensures that you understood the market dynamics and problems the team is solving, and keeps you on track.

Lesson 3

Use cases make great milestones.

Giving the team a "feature" to implement may work, but giving them a use case with a script on how it will be used in detail empowers them.

Being Agile in our environment meant we had to find a way to balance the needs of building a highly scalable, reliable architecture with the ability to bring meaningful functionality to market, quickly.

At first I sat with the team and we spec’ed out features for the short-term goals. The major players would sit in a meeting and discuss the overall architecture, pick major pieces of functionality to implement, and break them into short-term assignments, and set the goal. This was effective, and features were delivered as desired.

When we were far enough along to begin building the user interface and integrate the architecture, we decided to create a top-to-bottom use case as a milestone. We analyzed typical use cases, formed them into a series of user actions, and wrote out the actions in detail. These exercises became our "script".

The engineers were charged with enabling the script, using it to define the next features. With this empowerment, a new dynamic emerged. What was previously an outstanding, solid, diligent effort was taken to the next level – ownership. An additional spark of enthusiasm spread throughout the team. We were all able to rally around understanding how and why the feature was to be used, causing us to function even more effectively.

Since experiencing this success, I have been using the technique of use cases and scripts as the foundation for milestones, not only enhancing my ability to clarify the “why”, but as a way to empower the engineers to more effectively design the "how".

Lesson 4

Document, document, document.

Write down your decisions. Nothing is clearer in Agile than the fact you will make hundreds of additional decisions every week. To maintain the short development and release to QA cycles, you occasionally trade off the timing of implementing functionality, pushing one feature out in favor of another (in Agile, this is sometimes referred to as "spillover"). It's very easy to lose track of the spillover if you aren’t documentation-obsessed. At my company, like most, we use a bug tracking system.

When my list of tradeoffs became too long to transfer to my new notebook (OK, it was a list of 5, but I have very messy hand-writing), I started entering "feature requests" into the bug tracking system, and assigning them to myself. It is now a searchable, reportable set of features, all online for the world to review.

If you aren’t able to use your own tracking system, write down small notes from each meeting along with the rationale behind any design changes, just in case you ever need to refer back to it. I have also found using a Wiki invaluable for this effort. Everyone can enter decisions and rationale and it is fully searchable for future reference.

Lesson 5

It’s not about you. Empower the team (and trust them).

When I started the process, books on agile development indicated I should be very involved in everything. I tried it, but quickly changed my ways. Being over-involved made me feel important for about three minutes, and then I realized how impractical it was. As a one-person product management team, it's not possible for me to write out (or even think out) in detail every facet of the product’s functionality in a reasonable timeframe. I think it is more important to empower the team by providing enough information for them to act as surrogate Product Owners.

When given responsibility of ownership, even the quietest of team members will surprise you. While we were designing our installation process, the team started by putting together the proposed process. The first iteration of the design was closer to what an engineer would expect to do than an end user. And, from out of the bleachers, one of our newest team members said "Might be a nicer user experience if …" and went on to describe a clever way at achieving an easier installation experience for the end user. What an outstanding contribution! If I had forced my will onto the team, it is very possible we would have missed this opportunity to make a great hire be an even greater contributor.

By giving up some control, I was not a bottleneck, and we have a stronger team. We were able to do this and build a great product within our timeframe. Sometimes it is really nice to feel important, but more often it is better to be a strong team player.

Some will complain about this advice, and I fully acknowledge it is contrary to much of the information you may have read. So I’ll add this caveat: My team is senior, seasoned, and sensible. They make really well-informed decisions, and I trust them. If you aren’t as lucky, this technique may not be right for you.

Conclusion

Being Agile enables me to continually improve as a product manager and grow exponentially faster than I had in my previous work environments. In a waterfall environment, we reflected on the release and made changes after six months or a year of work as a team. In the rapid development cycle of Agile, I have reflection points every few weeks. I am able to take advantage of the milestones as a way to continue and improve on what works, and change what doesn’t. Evolution at its best.

Agile product management is also a big lesson on the importance of being a strong team player while building trust amongst your peers. I hope your experience with it is as positive as mine. Good luck!

Nicole Reineke is the Director of Product Management for Unidesk Corporation, a leading virtual desktop management software company. Nicole has more than 10 year of development and product management experience building IT applications, and uses the Pragmatic Marketing Framework extensively. Follow her @NicoleReineke or blog.unidesk.com.