Product Management Glossary (Part 2)
This is a continuation of my previous post where I talked about commonly used PM terms related to UI and design. In this post, I will…
This is a continuation of my previous post where I talked about commonly used PM terms related to UI and design. In this post, I will focus on engineering related terms since a majority of a PM’s time is spent with the engineering team.
Engineering + Product Management
Agile Development
Most technology companies use Agile methodologies (based on anecdotal evidence). The overarching philosophy behind Agile development is to have short, iterative and collaborative development cycles. One definition of Agile is as follows:
Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams¹
Each company can have its own flavour of Agile since it’s such a nuanced approach. For instance, the sprint duration and the structure of stand-up meetings can vary from company to company.
Sprints
A sprint is a short, time-constrained period during which the product development team (product managers, designers, engineers) aims to complete a clearly defined amount of work. They are a fundamental building block of the agile methodology. The idea behind sprints is to breakdown large, complex projects into digestible bite-sized chunks. A PM is in charge of scoping out, planning and communicating the details of each sprint with their stakeholders.
In my previous startup, I implemented weekly sprints because of the rapid pace of change in our product and limited engineering time.
Stand-up Meetings
Stand-up meetings are another crucial part of working in an agile environment. It is a daily meeting where the product owners, developers and any other core team members get together to stay informed of each other’s progress. Think of it as the huddle before games in sports where teammates strategize and calibrate. I am averse to having meetings in general (waste of time yada yada), so I used to ask the following three questions to keep the stand-up short and engaging:
What did you work on yesterday?
What are you working on today?
Are there any blocker issues that prevent you from reaching your goals in this sprint?
These questions set the playing field and lets the entire team be on the same page during the sprint.
Backlog
A product backlog is simple — it’s the prioritized to-do list of items. As a PM, you HAVE to be able to prioritize multiple requests from multiple stakeholders. A PM has to be able to say no too, but that warrants a separate post. A well curated backlog makes release and sprint planning easier. The backlog is also visible to the entire organization and a great way to televise all the things your team intends to spend time on. As such, it can be a great asset when negotiating with stakeholders or teams when they want additional work done from your team.
Do not let inertia set in
It is imperative to visit your backlog before every sprint to ensure that prioritization is correct and that the most recent feedback has been incorporated. A badly groomed backlog just sets you up for failure in your future sprints (ie. you will be building a shitty product).
APIs
Application Programming Interfaces (APIs) are the intermediary communication tool between two applications for data transfer. For example, when you login to Facebook, you are using Facebook’s authentication API.
You enter your login credentials on your computer
These credentials get sent to Facebook’s servers for verification
Once verified, Facebook’s servers send back an “OK” message to your computer
Voila! You are now authenticated via an API
I have oversimplified the concept but I found this post written by Petr Gazarov to be a great explanation.
User Stories
Agile methodology is focused on being user-centric. As a PM, you have to be empathetic towards your users and be able to convey their needs in a compelling manner to the engineering team. How do you do that? Through user stories. User stories are the building blocks of every sprint and are the smallest unit of the agile methodology.
A user story is an end-goal of what the software needs to achieve. It is not a way to describe a feature. A user story usually follows the following format:
As a ______, I want to______ so that ________
This format forces you to place yourself in the shoes of the user (persona) and articulate a story about why this change is needed to improve your product and their lives.
Good user story versus a bad user story?
Bad: A bad user story just describes a feature:
“The app needs to let managers approve time-off”
Good: A good user story explains who it is for and why it is needed and the impact it will make on the user
“As a Manager, I want to be able to approve time-off requests on my employee dashboard so that I can spend less time on administrative paperwork”
My approach to writing a user story revolves around the fact that engineers are your audience. So, here are some guidelines that I abide by:
Define what the completed state looks like. The engineer working on your story needs to know when (s)he can mark the story as done and move on to the next story
If there are specific steps to take before being able to work on that story, outline it. For example, is this story dependent on another story being done first?
Include any lo-fi or hi-fi mockups to help your engineers visualize the design
Include all corner cases and how to reach that state. In the above example, should a suspended employee be able to take time off?
I hope these two product management glossaries help any budding PMs out there. If you have any feedback or want me to write about any other PM related issues, drop a comment below. Happy prioritizing!
References
[1] https://www.cprime.com/resources/what-is-agile-what-is-scrum/