Let’s face it, technical debt is something that every Product Manager has to deal with on a constant basis — whether it’s making snap decisions that unblock your team so that they can keep working, short-cutting an ideal architectural solution because you have time-to-market pressures, or deciding to put off working on bugs found after a story’s been closed. While the common wisdom may be that you should never take on technical debt, the real world intrudes on such a fantasy each and every day, and if we don’t want to wind up in a death march that never sees the light of day, sometimes we have to make the choice to sacrifice some long-term stability in exchange for short-term gains. But how do you determine when there’s too much technical debt, or when the specific item of debt is too much to bear? That’s what we’re going to discuss today…
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…