As Product Managers, we’re often deeply and intimately involved in the processes that our companies use in their everyday business. Issue tracking systems, customer feedback systems, email and IM systems — there’s a neverending list of tools that we use on a daily basis to further our own (and others’) professional productivity. Having such a laser focus on the things that we do at work sometimes means that we forget that some of these very same tools (or tools like them) can be used to help ourselves on a daily basis in our personal lives. As I’ve taken on this blog, and written paid posts for other companies, I’ve come to value several tools for both professional and personal productivity that I thought it would be fun to share.
For the past three years, I’ve posted a list of five things that every PM should be thankful for (you can see the other installments here: 2014, 2015, 2016). It started as a bit of a lark, something to fit in with the holiday, but each year’s list has been more popular than the last, so it’s become something of an annual tradition here at the Clever PM. Just as in prior years, consider this an unranked list of five things to be thankful for — not an exclusive list, certainly, but without these things our jobs would be incredibly more difficult than they already are. If you have other things you’re thankful for, feel free to note them in the comments!
The concept of MVP is an interesting one in the Product Management world — interesting, in that just like the role itself, it seems to mean something different to almost everyone that you talk to. On one side of the spectrum, you’ve got the Lean Product folks who seem to think that a landing page without any other context is an MVP; on the other you’ve got people who seem to think that you’ve got to have a full end-to-end solution that’s just ugly to achieve an MVP. The truth, however, lies somewhere in between the two — as I’ve noted before, there are some key considerations that come into play when coming up with our MVP (When is an MVP *not* an MVP?, but there’s more to it than just understanding the “Minimal”, the “Viable”, and the “Product”. Ultimately, MVPs must all serve some purpose; otherwise there’s really no point in it.
During this year’s ProductCamp Seattle, I sat in on a great presentation by Dave Manningsmith where he discussed several dysfunctions of the daily standup ceremony (or “ritual” as he referred to it) that so many of us participate in on a daily basis. And it really made me think a lot about just how badly so many of us actually do in our standups — whether it’s because we’re used to status reporting in authoritarian cultures, because we’re really just teams in name only but still executing as individuals, or (most likely) because the organization has never really taken the time to understand why we do standups, so they don’t even understand that they might be doing them wrong. Here are some common anti-patterns and resolutions that will help you ensure that you’re at least closer to doing a standup “right” in the future…
I recently had a really great conversation with a fellow co-worker about how and why companies struggle with the adoption of agile methodologies like Scrum. It just so happened that he had come from a very large company where someone had undertaken something unheard of — they attempted to objectively measure the effect that Scrum participation had on a variety of employee metrics, including productivity, job satisfaction, and overall output. The interesting finding was that for teams who skipped any one of the five key Scrum ceremonies, their overall scores were literally no better than teams who maintained an old-school, waterfall approach — while every team that performed all five of the key ceremonies on a regular basis has scored vastly greater than their peers, across the board. Seeing this data in tangible, objective numbers really stuck with me, and I think it’s important to discuss just why these ceremonies are so important to successful adoption of agile processes.
One of the things that I love about the Product Management community here in Seattle is how close-knit we are, so when I reached out to Tricia Cervenan, a fellow Product Manager and General Assembly instructor, for her thoughts on the industry, the role, and what it means to her, I was not disappointed. I met Tricia a few years back at a panel discussion for General Assembly’s and have worked closely with her during our classes to help mold and modify the curriculum to best fit the needs of our students. I’m happy to have her as a returning judge for each of my courses, and more happy to mark her among my very close colleagues in the business!
In her own words:
Tricia Cervenan is a product manager at L4 Digital and part-time instructor at General Assembly. She has shipped over 15 digital products and is most proud of the teams she’s help to build while doing so. Tricia is a co-organizer for App Camp for Girls Seattle where she teaches 8th and 9th grade girls confidence and coding while taking them through the process of building iOS apps in a week. When she’s not building software or working with those new to the industry, Tricia finds joy in long distance cycling, world travel and a good cup of coffee.
I’ve been working on B2B solutions for a very long time (dating almost all the way back to the turn of the millennia), and in that time I’ve come to realize that far too many applications try to be everything to everyone, and as a result really wind up serving nobody at all. You can see this in many product designs that try to capture all of the possible things that you could do at a given point in time, rather than leading you through a logical path, or showing you the most likely things that you may want to do. As much heat as I give the “ribbon” change that Microsoft introduced in Office a few (many) years back — conceptually, it was the right thing. It focuses you on the specific things that you need to do in some contextual space, without requiring you to remember which specific menu item someone decided to hide that option under. While the rollout was challenging, in my opinion, the approach really encapsulates a concept that I like to call “build for the novice, enable the expert”.