Share one thing that you’ve changed within your organization that has made your team meaningfully more effective
www.lennysnewsletter.com
I’m traveling this week, so instead of skipping a week let’s try an experiment and throw out a question to y’all:
🤜 Share one thing that you’ve changed within your organization that has made your team meaningfully more effective 🤛
This could be anything from a new design review process, to how you approach meetings, to a sweet new template everyone loves. Click the big orange button below to share one thing that comes to mind, and upvote your favorite ideas — this should take no more than a couple of minutes. Go!
Keeping track of every piece of customer feedback we receive, and then actually following up after we've made improvements to let people know they've been heard. Most companies don't follow up, and it's been a game changer for customer engagement and spread.
I created a template in case anyone is interested in trying out our methodology
I'm in an engineering first org, so I had to introduce product into our development processes in a valuable and non-intrusive way.
I did this by introducing Product Discovery documents on topics that we want to address with the following structure:
1) Overview, goals, and non-goals: this defines the scope and boundaries of the discovery effort
2) User stories: this helps identify the spectrum of scenarios users may encounter
3) User needs: this distills findings into clear requirements from the product
4) Product requirements: this translates users requirements into engineering specifications for implementation
5) Illustrations/mock ups: this visualizes what an implementation might look like
6) User artifacts/feedback in appendix: these are notes/snapshots of user insights collected during discovery from meetings, chats, messages, or otherwise
I was blown away by the feedback from the engineers like "I clearly know what we need to build now", or "I better understand our users". I'm happy to say these docs are now prerequisites before engineers feel comfortable to write any code.
After reading Trillion Dollar Coach, I liked the idea of "Trip Reports". So I introduced a variation of that in our team meetings.
Every Monday morning, I asked the team to send me photos of their weekend/vacation. I collated it into individual slides and at the start of our team meeting we went round the room talking about your photos! (15 mins)
This had a positive impact to the team. We got to know each other as humans outside of work. We let our guard down before talking about work. Especially great for new starters!
After reading 📚 UX for startups and other UX books in my first 2 weeks after joining the startup, we experimented with setting aside a day where all engineers 👨💻 focused on a certain list full of UX annoyances (not bugs) then send out an email with all improvements as we ate pizza 🍕 while solving them.
🚨On D-day, there was only 1 engineer who was available because the rest had emergencies.
We (me as UX & Front-end of course after discussions with the PM) moved the tickets from:
'Design in progress' 👉'Ready for Dev' 👉 'In Progress' 👉 'Code Review' 👉 'QA' 👉 'Done'
🎉We managed to address 10% of all the UX annoyances.
After reflecting with the team 🧠, because we work in agile way, we all decided that for every sprint ♺, we will be picking 1-2 UX Annoyances 😡 and add them to the Backlog.
This was a victory for the team! 🙌 Now we are not just looking at Painkillers (PM vs UX) but also Vitamins!
😢Still trying to look for time to write the article.
Delivered monitoring / analytics with each feature implemented in the product. This made it easy to justify more budget by having a backlog of a pretty deep set of analytics by the time we were a few months into the project.
Example - feature to improve uptime, so while eng team built out that feature i built out the data pipeline to monitor uptime, to get a baseline + show improvement from feature. also had added benefit of giving us effectively real time feedback on effectiveness of feature.
1) Daily Virtual Scrum over slack,where team shares what are the things they are targeting to achieve that day. And at the end of day, they share the status update aganist each line item they shared in the morning. We replaced attendance process with this. It reinforces team to go through the allocated task and think as first thing in morning, before they start executing.
2) Product Reviews every week/bi-weekly. We keep changing frequency based on the backlog.
3) We started writing the mission, vision and stratgey for the subsequent products that we are planning to introduce. It helped me personally to avoid many mistakes we did in past based on this link where you shared, Lenny.
For placing orders to our supplier I created an automatic system that predicts how much of each item we need and cut down the time it takes to place such an order from hours to minutes.
Created a deck on business terms used at our company that many may not be familiar with. Things like MRR, ACV, CAC, CTR, ASO, etc.
The idea was to enable everyone to be more proactively involved in discussions whenever these terms are thrown around. Now we showcase this deck to every new joinee at the company during their onboarding!
We started to have "monthly social events" -- a rotating set of activity-based events that each person on the team would host. Anything from MassVR (https://massvr.com/) to Game Show Game Show (https://thegameshowgameshow.com/). The structure shifted a decidedly introverted team to becoming much more collaborative and for the newer folks on the team to ask others for help. This then set up a structure where we now have weekly "pod" meetings where various folks collaborate on technical design, coding, and strategy in a way that I never expected!
Normally developpers would do a "Technical Conception" before a project beggins, and that can take a few days or weeks.
What I do as a Product Manager is a "Pre-Technical Conception & Legacy study" before that, where I :
- Study legacy perimeter where the team will have to work on. Study all functional aspects. Write documentation (super important) to keep track of my studies. Explain how features & logic work.
- While studying functional, I also take time to note down all technical aspects that I can understand (ex: database structure of this functional perimeter, API calls during feature interactions, workflow, etc) or any leads/suggestions I can give to the developper so that it can help him do the Technical Conception faster.
This is a total new process I created in my team & company. Not only did it benefit a lot the team, but made the project deliveries significantly faster by making the developers obtain knowledge in advance and do very fast Technical Conceptions.
Our development time of projects went 300% faster.
For a less engaged team, I booked one hour every week for the team to present to each other something they are working on, new ideas, or any other topic. I sent them a Google slide template everyweek in advance so they can add the content they want before the session. It had huge success and it became a very engaged team, and they continued that process even after I moved to another team.
Moving our team from a back/front organisation to a feature team org. In every feature team we do have designers, developers and data analysts/scientists. The result was way better in term of team atmosphere and engagement regarding our product success!
Previously I worked at corporate where innovation was strictly defined. Was persistent with mgmt. in championing value of open innovation & eventually rewarded with dedicated Innovation Lab. Through it I intro'd VR to dozens, & it became focal point for visitors(esp. 👩🎓during 🏖️)
Documenting all decisions (even minor ones) by posting in the relevant Slack group. For larger projects, I'll have anywhere from 2-5 updates per day. I've found this especially important when working on larger features where there's numerous stakeholders and moving parts. Here's some of the benefits that have come with this communication style:
1) Reduce chance of something slipping through the cracks because of a lack of communication
2) Others have a chance to chime in and bring valuable context to a decision that's been made
3) Helps me keep track of all the decisions I've made
4) Increases transparency and trust amongst team members
Keeping track of every piece of customer feedback we receive, and then actually following up after we've made improvements to let people know they've been heard. Most companies don't follow up, and it's been a game changer for customer engagement and spread.
I created a template in case anyone is interested in trying out our methodology
https://coda.io/t/Customer-Feedback-Hub_tR3QcZZMHKW?previewTemplate=R3QcZZMHKW
I'm in an engineering first org, so I had to introduce product into our development processes in a valuable and non-intrusive way.
I did this by introducing Product Discovery documents on topics that we want to address with the following structure:
1) Overview, goals, and non-goals: this defines the scope and boundaries of the discovery effort
2) User stories: this helps identify the spectrum of scenarios users may encounter
3) User needs: this distills findings into clear requirements from the product
4) Product requirements: this translates users requirements into engineering specifications for implementation
5) Illustrations/mock ups: this visualizes what an implementation might look like
6) User artifacts/feedback in appendix: these are notes/snapshots of user insights collected during discovery from meetings, chats, messages, or otherwise
I was blown away by the feedback from the engineers like "I clearly know what we need to build now", or "I better understand our users". I'm happy to say these docs are now prerequisites before engineers feel comfortable to write any code.
Shameless plug - I wrote about my first year as a PM, and I'd love to hear your feedback and thoughts: https://blog.usejournal.com/my-first-year-as-a-product-manager-c34c0cac47f9
After reading Trillion Dollar Coach, I liked the idea of "Trip Reports". So I introduced a variation of that in our team meetings.
Every Monday morning, I asked the team to send me photos of their weekend/vacation. I collated it into individual slides and at the start of our team meeting we went round the room talking about your photos! (15 mins)
This had a positive impact to the team. We got to know each other as humans outside of work. We let our guard down before talking about work. Especially great for new starters!
After reading 📚 UX for startups and other UX books in my first 2 weeks after joining the startup, we experimented with setting aside a day where all engineers 👨💻 focused on a certain list full of UX annoyances (not bugs) then send out an email with all improvements as we ate pizza 🍕 while solving them.
🚨On D-day, there was only 1 engineer who was available because the rest had emergencies.
We (me as UX & Front-end of course after discussions with the PM) moved the tickets from:
'Design in progress' 👉'Ready for Dev' 👉 'In Progress' 👉 'Code Review' 👉 'QA' 👉 'Done'
🎉We managed to address 10% of all the UX annoyances.
After reflecting with the team 🧠, because we work in agile way, we all decided that for every sprint ♺, we will be picking 1-2 UX Annoyances 😡 and add them to the Backlog.
This was a victory for the team! 🙌 Now we are not just looking at Painkillers (PM vs UX) but also Vitamins!
😢Still trying to look for time to write the article.
Delivered monitoring / analytics with each feature implemented in the product. This made it easy to justify more budget by having a backlog of a pretty deep set of analytics by the time we were a few months into the project.
Example - feature to improve uptime, so while eng team built out that feature i built out the data pipeline to monitor uptime, to get a baseline + show improvement from feature. also had added benefit of giving us effectively real time feedback on effectiveness of feature.
Couple of changes
1) Daily Virtual Scrum over slack,where team shares what are the things they are targeting to achieve that day. And at the end of day, they share the status update aganist each line item they shared in the morning. We replaced attendance process with this. It reinforces team to go through the allocated task and think as first thing in morning, before they start executing.
2) Product Reviews every week/bi-weekly. We keep changing frequency based on the backlog.
3) We started writing the mission, vision and stratgey for the subsequent products that we are planning to introduce. It helped me personally to avoid many mistakes we did in past based on this link where you shared, Lenny.
https://medium.com/hackernoon/how-to-get-into-product-management-78c58bd9c8cf
For placing orders to our supplier I created an automatic system that predicts how much of each item we need and cut down the time it takes to place such an order from hours to minutes.
Created a deck on business terms used at our company that many may not be familiar with. Things like MRR, ACV, CAC, CTR, ASO, etc.
The idea was to enable everyone to be more proactively involved in discussions whenever these terms are thrown around. Now we showcase this deck to every new joinee at the company during their onboarding!
Public link to the deck: https://docs.google.com/presentation/d/1tC_p-ukMd8QMEFEU7bwUywB42-huKbF9H0K115gEqXg/edit?usp=sharing
We started to have "monthly social events" -- a rotating set of activity-based events that each person on the team would host. Anything from MassVR (https://massvr.com/) to Game Show Game Show (https://thegameshowgameshow.com/). The structure shifted a decidedly introverted team to becoming much more collaborative and for the newer folks on the team to ask others for help. This then set up a structure where we now have weekly "pod" meetings where various folks collaborate on technical design, coding, and strategy in a way that I never expected!
Moving over to Basecamp instead of using Google Drive / Docs / Sheets.
Normally developpers would do a "Technical Conception" before a project beggins, and that can take a few days or weeks.
What I do as a Product Manager is a "Pre-Technical Conception & Legacy study" before that, where I :
- Study legacy perimeter where the team will have to work on. Study all functional aspects. Write documentation (super important) to keep track of my studies. Explain how features & logic work.
- While studying functional, I also take time to note down all technical aspects that I can understand (ex: database structure of this functional perimeter, API calls during feature interactions, workflow, etc) or any leads/suggestions I can give to the developper so that it can help him do the Technical Conception faster.
This is a total new process I created in my team & company. Not only did it benefit a lot the team, but made the project deliveries significantly faster by making the developers obtain knowledge in advance and do very fast Technical Conceptions.
Our development time of projects went 300% faster.
The kanban view of the JIRA that we displays on TV's
Goal = stakeholders have a good idea of the status of their requests (bug, improvement, etc.) and we bring more transparency
For a less engaged team, I booked one hour every week for the team to present to each other something they are working on, new ideas, or any other topic. I sent them a Google slide template everyweek in advance so they can add the content they want before the session. It had huge success and it became a very engaged team, and they continued that process even after I moved to another team.
Moving our team from a back/front organisation to a feature team org. In every feature team we do have designers, developers and data analysts/scientists. The result was way better in term of team atmosphere and engagement regarding our product success!
Previously I worked at corporate where innovation was strictly defined. Was persistent with mgmt. in championing value of open innovation & eventually rewarded with dedicated Innovation Lab. Through it I intro'd VR to dozens, & it became focal point for visitors(esp. 👩🎓during 🏖️)
Implementing JTBD theory and framework a few years ago! It really didn't take much... The team embraced it right away.
Documenting all decisions (even minor ones) by posting in the relevant Slack group. For larger projects, I'll have anywhere from 2-5 updates per day. I've found this especially important when working on larger features where there's numerous stakeholders and moving parts. Here's some of the benefits that have come with this communication style:
1) Reduce chance of something slipping through the cracks because of a lack of communication
2) Others have a chance to chime in and bring valuable context to a decision that's been made
3) Helps me keep track of all the decisions I've made
4) Increases transparency and trust amongst team members