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…
The Product Lifecycle
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!
10 Questions: Teresa Torres
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:
Goals & Non-Goals
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…
The Clever PM’s Hierarchy of PM Needs
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…
- « Previous Page
- 1
- 2
- 3
- 4
- 5
- 6
- …
- 11
- Next Page »