I am excited to share that I have completed the University of Alberta Software Product Management Specialization.
TLDR: I liked it, would recommend, but don't be offput by the "Agile" talk.
It includes the following courses:
- Introduction to Software Product Management
- Software Processes and Agile Practices
- Client Needs and Software Requirements
- Agile Planning for Software Products
- Reviews & Metrics for Software Improvements
Here are my notes from the courses. Things I found interesting and worth highlighting:
Introduction to Software Product Management
Only 2 modules in this course. I did not think anything was noteworthy.
Software Processes and Agile Practices
Honestly, I did not expect that much focus on "Agile". It appears to be a very big part of Product Management.
Another thing mentioned in this course is pair programming. This is something that I have heard before, but in my experience it is not very common.
Pair programming means that two developers work side by side at one computer to develop code.
This is like code review on steroids. Instead of periodically reviewing code, code is reviewed all the time by the other person in the pair.
You might be thinking that this requires doubling the human resources needed for the future. But it actually is the case that two programmers working together can produce more than two programmers working separately and independently. And it's at a higher quality. Like I said before, this also goes back to fostering courage. Programmers are more likely to take some calculated risks because they're not doing it alone. This leads to innovation and high quality products.
This is perhaps the most insightful part of the course, and possible the whole specialization. And one might argue it's not "Product Management"-related. But I think this is a key concept in relation to the business of software.
Looking back at my career, I have never been part of a team that did pair programming. The closest I've come is working on personal projects with my friend. Maybe that's what professional development should aspire to be like. Like you are working with your friends on a project you all are passionate about.
And another thing that comes to mind is that programming with Cursor kind of feels like pair programming. Cursor helps me write code, and I can technically request feedback any time. I recently lost access to "Cursor Pro" at work. Man, suddenly it felt much more lonely. I did not expect that. That and the pain of manual coding.
Client Needs and Software Requirements
This is perhaps the most "Product Management"-related course in the specialization. It's all about understanding the needs of the client and how to translate those needs into software requirements.
User stories follow a very specific format. As a blank, I want to blank, So that blank.
The final blank of the user story. Specifies “why” the user story is needed in the first place. This is often skipped when user stories are created. But it offers a key insight into their requirement. It gives context to the requirement about the value or benefit it offers, which aligns with the product's goals or vision.
Business value, and more importantly quantifiable business value, is the key to successful product management. Too often PRD is just a list of features, without any context of why they are important or what research was done to justify them. What metrics or events will determine if the project is successful? And what are we going to do if it's not successful? Risks and consequences are important to consider.
INVEST is a mnemonic to help you remember what makes a good requirement: Independent: story can be developed separately from any others regardless of when it's implemented. Negotiable: general enough for your team and your client to work around the implementation. Don't focus on the specific, technical details of how the requirement is to be satisfied. Valuable: don't make fluffy, busy work. Estimatable: if you can't estimate how long it takes to develop, you probably specified an Epic. Small: break stories down as much as possible, to avoid Epic ^ Testable: define and use acceptance tests.
Makes a lot of sense. Nothing much to add.
Story maps are a great way of representing your product backlog with more visual detail. It's a method for taking user stories from your backlog and grouping them into more specific functional categories.
I found story maps the most interesting part of the course. I enjoy visualizations. I have attempted various code base visualizations at work, where I deal with a lot of code. But I never thought about visualizing a product backlog. There is a lot of data in Jira. And as soon as I saw this in the course, I made a todo item for me to come up with something at work to visualize our product backlog. Whenever I get a free minute. It'd be awesome if Jira had something like this built in. It probably does, but it's behind the "admin wall".
Agile Planning for Software Products
This course had a few interesting software development anti-patterns:
Fire Drill
A Fire Drill is what happened when developers do too little work throughout the majority of the project and then all of a sudden need to make a big push toward the end.
The Fire Drill is dangerous, because it often leads to sacrificing code quality in favor of getting the product out the door quickly.
I feel like in my career I rarely had any hard deadlines. And with some good planning, you cover all the "known" things that might take a lot of time. Of course, there are always some surprises at the end, that get discovered in the "testing" phase. You might call that a Fire Drill. But usually releasing things later is not a problem, as long as these surprise delays are communicated to stakeholders.
Heroics
Heroics is way of describing what happens when your project relies on one developer's nearly superhuman technical skills to get the project done. This is risky. People become reliant on that person to get the work done, even outside of the big push at the end.
I would love to think I'm guilty of this. It would sure be great to have a superhuman skill. And it would be even better to be on a team of people who are all superhuman.
Recently Andrew Ng posted about 10x engineers. He suggestes that AI will unlock more professions to make 10x impact. Especially if they master automation with code.
Death March
When management struggles to get the development team to believe in the work they're doing?
Everyone on the development team knows that the project is destined for failure, but everyone continues to build a project anyway, out of obligation. Imagine the terrible consequences of this.
I feel like in my career I have usually been optimistic about my work. Or at least I manage to sell myself on it. However, looking back at the projects I worked on, and how many of them failed in various ways, I don't really know where this optimism comes from.
Groupthink
When coming up with a solution, let individuals come up with their own ideas without talking to each other. Then, everyone comes back together and the team can discuss each person's ideas in turn.
Sounds like brainstorming. In my experience, we don't do enough of this.
This prevents one or two people from dominating group discussions.
That is unless the discussions are not behind closed doors to begin with. I mean, in a private zoom meeting.
Usually the development team is presented with a solution, not a problem. And then the feedback is requested for the existing solution. And sometimes the feedback doesn't even matter in the end.
But we do avoid groupthink in our story pointing meetings using planning poker.
Loose Cannon
A loose cannon is a person who makes significant project decisions without consulting the rest of the team. This isn't heroics, like I discussed earlier in this lesson. It's recklessness. Sometimes the loose cannon just wants to cause trouble. And sometimes they want to prove their own worth. An ideal solution to the loose cannon is to try and get an individual to see their own behavior as destructive and make steps to change it.
Personally,I feel guilty of this. I have been accused of communication issues in the past. And for me it's usually the lack of awareness of consequences of my decisions to other people. But I would argue that agency is a good thing, as long as you communicate it to people affected. Call it "taking initiative".
Intellectual Violence
Intellectual violence is as much about the developer's inner world as any of the other anti-patterns I've described. Intellectual Violence can be used by loose cannons, making meetings unbearable. Intellectual Violence is a situation where a person uses their advanced knowledge in an area to intimidate others. As you might imagine, behaviors like this can cause team members to feel unappreciated and unimportant. To address an intellectual violence problem, try talking to the individual in private. Ask them to reflect on how their behavior affects others on the team.
Actually, I have recently been accused of this too. After a retrospective meeting, my manager talked to me privately about my behavior. In the retrospective I called out my dissapointment in a colleague for mismanaging a project. In the words of Dwight Schrute "I get a little frustrated when I'm dealing with incompetence". Wouldn't want my colleagues to think of me as Dwight, but a lot of his quotes hit very close to home for me. What does that say about me?
Gotta keep each other accountable without naming names.
Reviews & Metrics for Software Improvements
A big part of this course was again about Agile practices.
At my work we have a daily standup where we discuss what we did yesterday, what we are doing today and what we will do tomorrow. It's a zoom call every monday, wednesday and friday. And a slack message on tuesday and thursday.
A common challenge is that people might be late to the standup. In this course I learned about the "Last arrival speaks first" method. Which is a fun way to encourage everyone to come to the daily standup on time.
And I also learned about the Artifacts Contest Exercise: participants are encouraged to bring artifacts related to a project, explain their signficance, talk about them as a group, and in the end vote on the artifacts and award prizes: most important artifact, most unusual, most creative. A fun addition to the retrospective meeting.
I expected more from this course. I feel like what happens after launch is a weak spot for product managers. In my exprience, product managers are eager to jump to the next thing on the roadmap, without continioulsy reflecting on projects they have launched.
Conclusion
I think this is the best Coursera has to offer for Product Management. It's a good overview of how software development is done in the tech industry. I would recommend this to anyone who is interested in Product Management. But be prepared for a lot of "Agile" talk.
Related things
Interviews with world-class product leaders and growth experts to uncover concrete, actionable, and tactical advice to help you build, launch, and grow your own product.
Andrew NG: AI Product Managers Will Be In-Demand
As the cost of building AI products falls, demand for people who know what to build will rise. Get ready for an explosion in AI Product Management!
IBM: AI Product Manager Professional Certificate
I've done 7/10 of these IBM courses, and I prefered the University of Alberta specialization.