Last week Liam invited me to participate in a webinar titled “Pivoting Product and Product teams through a Crisis”. It was a real honour to be invited, as the panel was made up of a number of great product leaders from Sydney. Mable in particular has seen some big swings in supply and demand, as well as winning a very exciting Department of Health contract.
If you’d like to view the webinar, please see this YouTube video:
We recently started moving toward Agile software development at work, and I was feeling a bit uncertain. The core reason for this uncertainty was that Agile is a developer-centric methodology and I didn’t understand how I fitted in as a Business Analyst, Project Manager and/or Product Manager.
Now I am a big fan of constant change, I just felt that developers were being given tasks that (despite being scoped user stories) still contained a large number of unknowns. I didn’t know if I trusted them to call me in when they got stuck, rather than finding the quickest route themselves. Additionally the roles of Project Manager, Product Manager and Development Manager were stepping on each other’s toes. Normally I am happy to write the requirements up front and then manage the project. Now there were no complete signed off requirements documents, project management was on a wall and the development team was in control. What am I meant to be doing? I am not someone who likes to sit back and wait to be called upon! I eventually found the following presentation, which was literally one of the only sources I can find about how Agile development management is meant to work:
Even though I am only just beginning with Agile I felt the presentation gave me a good sense of where I fit. What are your experiences in Agile management outside the development team?
I was looking for good Product Management reading material, and was referred by a friend to the book “Getting Real” by 37Signals.
What did I like?
This book gets straight to the point, there is no bullshit whatsoever and it makes no apologies for that. Equally there is no room for bullshit in the product; decide a goal, keep the budgets tight, keep the team tighter, listen to the customer (at least when they bang down the door) and just execute the hell out of what you are doing.
This book is a reminder that building a product is not just about technically executing. Many usability, sales, HR and marketing issues must be addressed to deliver a successful, well-rounded product. You need to reflect this well-rounded nature too, everyone should take support calls, think of usability, write blog posts etc.
What didn’t I like?
There are however some minor things I don’t agree with. I think exit surveys are valuable, there should be a formal suggestion gathering and prioritisation process and there is a limit to how much information you should place online. If you have a mass appeal, generic app then I think these rules are a little different to someone developing a niche app for a specific market. Apart from these few items, I was nodding the whole way through the book.
Conclusion
This book embodies the entrepreneurial spirit of today’s web app developers. Put your heart into the app, and then put your app out for everyone to see. If you are a motivated person who wants to focus your vision and energy, then this book is for you.
Powered by WordPress & Theme by Anders Norén
