When we manage product development for organizations, we work for hire. The company hires you, pays you a wage, and in return, your intellectual property belongs to them. When you’re creating a product larger than one person can create, this is an excellent proposition. While “one person” may have had the original idea, we need
Many people draw distinctions between people who do management-kind of work and people who do “individual contributor” kind of work. I’ve been asking if they mean individual work or team member work. Sometimes, they do mean individual work. More often, they mean team member. Our culture shapes our language. (And, our language shapes our culture.)
During Agile 2018, Jerry Weinberg died. Shane Hastie and I had already agreed to do a recording of some sort while at the conference. We invited Esther Derby and turned our time into a lovely podcast about Remembering Jerry Weinberg. Yes, I was quite emotional. I’m human. I wrote a post about some of my
When I teach any sort of product/project/portfolio management, I ask, “Who believes multitasking works?” Always, at least several managers raise their hands. They believe multitasking works because they multitask all the time. Why? Because the managers have short work-time and long decision-wait time. If you are a manager, your time for any given decision looks
Consultants and writers share a common problem: we are business owners. That means we manage our businesses. Yes, I manage my own product development and my business. The great Joanna Penn interviewed me and the podcast is now live: Strategy And Business Plans For Authors With Johanna Rothman. If you write and self-publish, you should listen
Sometimes, teams have trouble releasing their work, showing the value of the work they’ve completed. There are many possible reasons for this release problem: The team doesn’t have sufficient working agreements about what “done” means. I’ve written about frictionless releasing. In Create Your Successful Agile Project, I wrote about the done, done-done, and done-done-done words we
I was on vacation last week, thinking about value. Depending on my role, I might think of value as: Delivery of a feature or story, assuming it’s the right level of quality and when I want it. Information about the story. This might include information from the team about what they think about this story,
Ryan Ripley interviewed me on his podcast, Agile for Humans 83 about Create Your Successful Agile Project. We had a blast. I didn’t stint on my opinions or on my experience with agile teams. One of those opinions was about teambuilding, which I wrote about in Creating an Environment of Teamwork. The other opinion (based on
Back in Manage It!, I suggested that for requirements, the questions should be, “How little can we do?” and still have a great product. My argument was this: the longer the project (regardless of approach), the more risk there is. Can you reduce risk by reducing the requirements? That would allow you to release earlier
Let me summarize what I’ve been talking about in these posts. The problem I’m seeing is that too many teams and organizations plan too much in too much detail too soon. Instead of architectural BDUF (Big Design Up Front), it’s project planning as BDUF. They expect one single person (a product manager or a product