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!
As an active member of the Seattle community of Product Managers, I’ve been fortunate enough to find many opportunities to engage with fellow Product Managers as well as those looking to make a break into the role. Between my work with General Assembly as a part-time instructor, my volunteer efforts as a board member of our local Pacific Northwest Product Management Community, or my presentations at ProductCamp every year, I enjoy sharing my knowledge and experience with those who seek different perspectives on old problems or just want to hear a good old war story. The fact is, we all have something to impart on those around us, and we should take any opportunity we can to share with those around us.
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:
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!
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”…
A common theme in online discussions and forums around Product Management lies in how to level up our skills and be a better Product Manager. While there are a lot of different options available, just as there are as many different aspects of Product Management to focus on, there are some very specific areas that any given Product Manager can assess themselves in and decide what next steps they want to take to become a better Product Manager.
There’s a term that gets floated around the Agile world by what I like to call the “textbook Scrummers” that really bugs the crap out of me, so much that I decided to write an article about the concept, and why I think it’s a wrong-headed, anti-agile concept. The concept is known as “ScrumBut” (a shortened form of “We do Scrum, but…”) and as the folks at Scrum.org describe it:
ScrumButs are reasons why teams can’t take full advantage of Scrum to solve their problems and realize the full benefits of product development using Scrum.
In theory, this concept sounds harmless — after all, Scrum is a very specific methodology, with specific ceremonies and deliverables that are designed to achieve specific goals and specific benefits. The problem lies in the fact that these methods are not the only way to achieve those goals, though the companies who provide Scrum training would be loathe to admit it. Here are a few reasons why “ScrumBut” really isn’t as bad as those “textbook Scrummers” might have you believe…