A Product Manager on the Front Lines, Part 2

3 min read Original article ↗

image

Our interview with Blurb, CNET and GOOD veteran Jack Lyon continues…read Part 1 here!

Who do you interact with?

Nearly everyone in the company. Primarily with the people on my immediate team: Product Managers, Designers, Engineers and QA. But, as I’ve worked on many content-heavy websites, I meet almost daily with the Editorial team, our Data Analyst and Marketing. I also meet daily with members of the Executive team to communicate status. It can be fascinating, as each group is evaluating the web site in such a completely different way – and rightfully so. It’s a good reminder that context is essential for everything we’re building.  

What tools do you use?

For requirements and wireframes, I tend to use the more classic tools: MediaWiki, OmniGraffle, Photoshop, and Google Docs. I’ve toyed around with online services like Balsamiq, and Axure, but none of them have really stuck for me, yet. 

For sharing and discussing design comps, I still think Basecamp is the best. It took me a while, but I do prefer Pivotal over more project-heavy tools like Jira. If you use it right, it can pull double-duty as a bug tracker and user story bucket. And, obviously, GitHub for version control. 

Finally, for metrics, I’m still a big fan of Google Analytics. While it can’t tell you absolutely every metric you can dream up, all the important stuff is there, and you don’t have to worry about tagging things a specific way every time you implement something new. Their heat mapping features are pretty good too.    

If you could change one thing, what would it be?

Nearly everywhere I’ve worked, there are no shortage of incredibly creative and intelligent people – so there’s never a shortage of truly interesting ideas. Be it anything from a brilliant new feature to a really smart way to refactor some existing code. Typically, only the best of those ideas make it onto a product roadmap. But, even then, the list ends up being massive.

What often ends up happening is a large debate, and the roadmap is built out to a full year. Mainly to make sure all those ideas are represented somewhere. Yet, I’ve never seen a project priority stick for more than three months. Because things change: new clients come on board, brand new projects become the top priority, the team changes players, technical problems arrive, or we’re pivoting in a different direction.

I have yet to be 100% successful at it, but I’d like to figure out a way to make the product roadmap process more closely match the agile methodology. So nothing project specific was projected beyond three months – aside from “all hands on deck, we’re completely rebuilding the whole site” types of things.

That’s not to say you shouldn’t have a 1, 3, 5 year strategy. But, planning specific features and sprints for December when it’s June is almost always unnecessary. By the time September rolls around, priorities have completely changed. As they should.