So – the strategy is clear, the thinking is exciting, the opportunities immense. What’s left now is to get it done.
And its not all easy, and its not all fun. So how do you slog through the minutia? These details that can be painful to document are so important to success, so – what’s the best way to approach them. In my case, I’m working on a Product Requirements Doc for a client. (I’ll do anything in the name of a great outcome). The outlines of the product are clear and everyone’s excited about the product direction. And still – getting every detail on paper is taking longer than it should, and delivering less value than it should.
The answer here depends on the circumstances, and who you are, and what you’re trying to achieve. But I think the best weapon is a buddy. Have someone to walk through the details with, and instead of a boring, painful, process, you suddenly have a vibrant conversation.
Who’s your buddy? Well – in the case of a Product Requirements Document your best allies are Design and Engineering. They each bring great insight to the table, and its essential to be in lock step with them. This small step is, in fact the first step toward an Agile methodology.
The Agile process is one of the most productive, efficient and altogether engaging team structures. In this process, design, product management and engineering get together, define the general outline of the product, and take a deep dive on a piece of it. Then, engineering goes and builds that piece, and design and product management go deep on the next piece. Then engineering gets involved again, and so it goes. Iterating, learning, iterating and learning. I’m a huge fan of this process, and most engineers I know like it too.
The key tools of the process are collaborative communication, trust and respect. People need to be on their toes and know you are too. The result is usually a highly aligned team, with a high degree of collegiality, and a killer record for getting things accomplished. People work in parallel, but not in isolation. Engineering isn’t left waiting while product management figures stuff out, and product management isn’t left with the huge burden of arranging every detail on a platter for
There are pros and cons to this method. The pros is that it can dramatically reduce schedule risk, gets all the best minds in synch, and can be very responsive to changes in requirements and learning. The cons, is that if you must have extensive face time. If part of your team is half way around the world, it can be extremely difficult to achieve this level of communication. I’ve not managed it yet myself. But, I’m sure that if I could, the productivity of the team would soar, as would morale.
Has anybody out there been successful with Agile across continents?
But Agile is not just for Engineers. Agile tactics are very well used in design, marketing and any other part of the business where cross-functional collaboration is key, and parallelism is important. There are great books on the subject, but I think the best way to learn about the method is to chat with people using it, or even better, attend some sessions. I can hook you up with some, if you like. Just ping me at deb at productfour dot com.