In many organizations, conflict is part and parcel of the culture — some conflict can be constructive, some destructive, but most of it can just be downright annoying. And, because we often sit right in the middle of all of the random agendas, battles of ego, and emotional storms that can rage throughout the company, Product Managers often wind up dealing with the outcome of these conflicts if we’re not pulled deeply into them by one or more of our stakeholders. And while it can often be tempting to take on all comers, to defend your territory and your teams to the bitter end, the sad truth is that all too often, these conflicts simply aren’t set up in a way for us to “win” — and seeking that extra mark in our “W” column can often be counterproductive rather than helpful in the long run. All of the best Product Managers know that sometimes when there’s a fight that you’re not going to win, it’s far more important to lose gracefully than it is to die on a hill for something that ultimately didn’t really matter much.
This post comes courtesy of a direct request from one of my supporters over at Patreon, who asked me if I could give them a 10,000 foot-level overview of the Product Lifecycle from ideation to delivery. While nothing here should be terribly earth-shattering or world-changing, I think it’s important for us as Product Managers to stop on occasion and think about how things should work for us from the point of an idea to the days supporting a thriving product. So here’s my personal take on the subject — as always, if you have thoughts or comments, feel free to drop them here or hit me up on Twitter!
I’m excited to kick off the new year with a new installment of my ongoing “10 Questions” series, surveying leaders in the Product Management world for their thoughts on the fundamentals of Product Management as well as questions related to their specific areas of expertise. For this January’s article, I reached out to Teresa Torres who is an amazing product discovery coach working out of Portland, Oregon — just a few hours south of me. She’s also the primary author of an amazing product blog at ProductTalk.org. I’ll let Teresa introduce herself to you in her own words:
Teresa is a product discovery coach who helps teams gain valuable insights from their customer interviews, run effective product experiments, and drive product outcomes that create value for their customers and their businesses. She teaches teams how to connect the dots between their research activities and their product decisions, inspiring confidence that they are on the right track. Recent clients include Allstate, Capital One, The Guardian, and Snagajob.
Before becoming a coach, Teresa spent the majority of her career leading product and design teams at early-stage internet companies. Most recently, Teresa was VP of Products at AfterCollege, an Internet startup that helps college students find their first job. She was CEO of Affinity Circles, an online community provider for university alumni associations and a social recruiting service used by Fortune 500 companies. She also held product and design roles at Become.com and HighWire Press.
Teresa has a BS in Symbolic Systems from Stanford University and an MS in Learning and Organizational Change from Northwestern University.
And, without further ado, Teresa’s 10 Questions:
One of the most important part of our jobs as Product Managers is setting goals — goals for ourselves, goals for our teams, and goals for our products. Goals are important — they set the North Star for us to know where we’re going, why we’re going there, and how we know whether or not we’ll be successful when we get there. Properly-formulated goals are an essential component of being a successful Product Manager. But how many of us think about non-goals? Those things that we are intentionally choosing not to do in a given project, the things we don’t expect to change due to our efforts, or the subject matter areas that (for one reason or another) we don’t want to address at this time, with this team, or with this project. Non-Goals are just as important as actual goals, and here are a few reasons to keep them in mind in your next kickoff session…
So, another year is starting up, and we’re just now starting to unpack ourselves from the holiday break that so many of us take time to enjoy with our families and friends. The best thing about a new year is that the future really is a blank slate, 365 days to make of them what we will. Sure, there’s carry over from last year, but there’s far more to look forward to than to look back on. It’s the perfect time to stop for a moment and take stock of what happened last year, what you want to do this year, and how you’re going to make 2018 more successful than 2017!
There’s a well-known theory in psychology known as Maslow’s Hierarchy of Needs, named after its creator Abraham Maslow. The concept behind this theory is that as human beings there are certain needs and interests that we seek to fulfill in a predictable priority — from physiological needs for food, water, and sleep up to social needs of belonging to a group, all the way to becoming independent, self-actualized creatures — the “best that we can be.” It’s a very interesting concept, and one that immediately came to mind in a recent Twitter discussion that I had with a fellow Product Manager named Gasca. Gasca proposed that the “intersection of business, development, and design” wasn’t really sufficient to describe what makes a Product Manager excel, and added a circular diagram to the discussion which immediately prompted me to think of the whole idea more in terms of Maslow’s Hierarchy — just what is it that makes a good Product Manager better, and how can we structure our approach to building skills and refining talent to “level up” our co-workers and peers to make the me most self-actualized Product Managers we can? I don’t pretend to have the full answer, but here are some thoughts, using Maslow’s Hierarchy as a model…
I was called into a meeting with a team here in the office a couple weeks ago because they told me they had a “question” about the estimations that they were doing. As we started talking, it became immediately apparent what the problem was, they were getting into arguments about whether their estimates were “too big!” Apparently, someone had told them that they “couldn’t” have any stories that were above a certain value, or at least that’s how they took the directions they were given. I stopped them for a minute and had a quick discussion about the reasons why we estimate stories, and why it’s incredibly important for the story points to reflect the size the team thinks the work is, regardless of what other people “want” them to do. I walked away to leave them to their work, and was entirely unsurprised when I saw some 20-pointers land on the backlog. Far too many teams suffer from some malady similar to that of this team — they forget why we’re asking them to estimate, so they start to engage in anti-patterns that undercut the very purpose for which estimation exists. In a follow-up conversation with another member of our Product Team, I started to think about how to describe Story Points as something other than “estimates” — and I came up with the idea of them as a “signalling tool”…