#ProductDiaries is a documented series of my experience as a product manager — what I’m doing, what I’m learning, and what I’m changing.
What I did:
To kickoff a project, I set up a sync with the product designer and developer (PDD being product & design & development).
This meeting comes after we’ve identified a problem, gone through working sessions and design iterations to come up with a proposed design, and I’ve written a spec/PRD that the developer has reviewed.
This is a space to ask questions on what the spec might be missing or to discuss technical constraints that have appeared before the project starts. Therefore, the structure is more developer centered with myself and the designer there as resources to answer questions, clarify confusion, or provide support where needed.
In this sync, the developer (engineer?) asked if we’re reusing components or building from scratch. The reason being because we wanted to alter how people sign in on one of our flows and the designs were net new screens. However, another software team already has screens that can be used for the sign in experience.
The preexisting screens are not as modern of a design so both the developer and designer wanted to put in the tech work to build new screens.
However, I decided to keep the scope of the project smile and tradeoff modern design for shipping fast. This isn’t always the right call: you first have to know why the project is being built, what goal it serves, and what the decision making priorities are.
Why I did it:
The point of this project was to improve the ability to sign in and drive parity across platforms, so I chose shipping basic functionality fast to drive customer volume over investing in a overall better design. Though better design is useful, the impact/pain of not having the functionality outweighed the impact/pain of not having it be the most beautifully modern.
Being a product manager means making decisions that have tradeoffs and it could be argued that I made the wrong call but with the current body of evidence — we’re losing customers due to extra friction in signing into their accounts-I made what I believe is the best choice. If I were presented with evidence that the design as opposed to the functionality were a greater pain to users, I would’ve made a different choice.
That said, I advised that we adjust the headers on the reused screens to be contextually relevant else risk confusing users on why it has a header that’s relevant to a different flow entirely. So we saved time in reusing components but do have to make some tweaks so we don’t lose customers from frustration in interpreting the copy.
What I would do better:
Our developer ended the meeting by saying ‘just one more recap so we’re all in alignment’ and summarized the decisions made and next steps and owners for us.
I consider this my job as the PM. I’m grateful to him for doing that for us and viewed it as a reminder on how to operate effectively as opposed to overstepping/a sneak diss on my meeting management.
I put that summary of next steps and owners in our project’s Slack channel so that we also all have it to refer to in writing since recall is imperfect and verbal agreements can be misinterpreted or misremembered.
Moving forward, I need to myself be the one who drives the summary and next steps with owners as well as putting it in writing with all relevant stakeholders (even if they did not attend the meeting).
