How do you stack up?
Let’s get started off with the elephant in the room…there are WAY far more than 10 practices that are shared among “highly effective” solution professionals. This record is, for me, far more of a “greatest hits” list — the types that I feel when practiced routinely deliver the most significant affect on your personal get the job done, and encompassing groups. Let’s leap suitable in.
I think this one is significantly applicable in this new hybrid-remote entire world, where by our calendars fill up 50% quicker than they did just before (and they currently stuffed up rapidly!). “Deep emphasis time” refers to un-interrupted time exactly where you can dive deep into whatever category of function you need to make development in (discovery, solutioning, start prep…you title it). “Deep concentrate time” does not exist as 15 moment time blocks amongst meetings, by the way. Quite a few say that to be most productive, a PM needs 4 several hours of this time each and every working day. Yikes. How do you stack up? Remaining clear for a second, on a truly great day I maybe have 2 hrs of this time. 4 hours may perhaps be unachievable for the several of us that do not are living in this utopian globe, but as they say…shoot for the moon, and if you miss out on you’ll land among the stars.
Many well recognised, successful PMs say that to be as efficient as we have to have to be, we have to have 4 hrs of this time each and every day.
Alright, so this a person and the last 1 go hand in hand. You will by no means create that “deep emphasis time”, if you never study how to wrestle you calendar to the ground. Let us speak about meetings for a moment. If I questioned you, “What is the function of a meeting? When must a meeting be a conference, and not an advert-hoc online video contact, Slack concept or email?”, how would you answer? Here’s how I could respond to: “The function of a meeting is to dedicate time to collaboratively operate toward accomplishing a discrete intention that cannot be attained by asynchronous work.” There are two crucial words that I want you to target on (I bolded them for you — you are welcome!). “Collaborative” and “discrete goal”. Numerous meetings keep the guise of a collaborate dialogue, but in truth it’s just an possibility for one particular man or woman to chat at other men and women (City Halls and identical conferences are exceptions). Also, a lot of conferences do not have an true purpose! It’s just a weekly “let’s chat about X”. Until a assembly carries with it the capability for a team to collaboratively create a resolution which necessitates synchronous communication and creative imagination and/or has a unique objective that the conference owner hopes to carry out in just the time, it is possible a waste of everyone’s time. Kindly send them a information on the aspect and ask about these two things. If you get again a hum-drum remedy, enable them know that respectfully you will sit it out so that you can get some other operate carried out. This is in particular crucial for the dreaded weekly recurring meeting. This normally takes some follow and it truly feel confrontational at initial, but listen to me out — you are NOT performing your crew, small business or prospects justice if you do not treat your calendar this way.
The intent of a meeting is to dedicate time to collaboratively get the job done towards accomplishing a discrete intention that can not be attained by asynchronous function
Let’s maintain the “scrutinizing your perform artifacts” teach heading. When you are not seeking at your calendar, there’s a excellent chance you are glancing over your job administration “artifact”. Probably for you this is sticky notes, OneNote web pages, or a process administration device like Monday.com. Whichever it is, I believe we can all concur that the working day-to-day jobs pile up Quick. But can I permit you in on a little top secret? (This is just one that I uncovered from Shreyas Desai). The magic formula is that not all duties are produced equal. Shreyas established this framework known as “LNO”, which stands for “Leveraged, Neutral, Overhead”, and it is powerfully uncomplicated.
The simple idea is that some jobs are “Leveraged” — indicating that accomplishing the process will produce you 10x the results of a Neutral activity, and then there are overhead duties, which give you a <1x the results of Neutral tasks. Simple enough right? Here’s the part that really blew my mind: For your L tasks do a great job, for N tasks do strictly a good job, and for O…actively do a bad job. “WHAT?! John, you’re telling me to do a BAD JOB AT MY JOB!?” Yup. The reality is that MANY of the tasks that clog up our lists are “O” tasks. They produce little value and the distinction between doing a great job, and a bad job, is almost invisible. So just get them off your list as quickly as possible, and keep your focus on the “L” tasks, and when those are done, the “N” tasks.
The secret is that not all tasks are created equal.
This is a fun one, and if my hunch is accurate, one that not a lot of people employ. It’s pretty simple, too. At many companies that only time we get feedback is during annual reviews, and if we are lucky, a quarterly version of that. The irony is that due to how infrequent this feedback is provided, you miss a lot of time to put this feedback into practice. This is why I am talking about a feedback loop, here. A loop is something that circles back to where it started. And like a loop, good feedback gives a person the ability to hear the feeedback, quickly work to implement, and then get feedback again. So here’s my tactical advice for how to build these loops into your day.
First, if your leader/manager/boss does not meet with you weekly, ask that they put a recurring 1:1 on the calendar (and yes, this is a meeting you SHOULD keep 😆). Make sure during these meetings they are giving you constructive feedback on where you are doing well, and where you can improve. Second, sprinkle on your calendar recurring 15 minute 1:1s with the developers and designers that you work with on a day to day basis. You can keep this light and do this every 6 weeks with each person, or monthly if your team is in “flux” and you need a lot more feedback. The purpose of these non-managerial 1:1s is simple — ask how you are doing for THEM, ask if they feel informed and empowered, and if they want you to do anything differently.
…like a loop, good feedback gives a person the ability to hear the feedback, quickly work to implement, and then get feedback again.
This one is as simple as it sounds. If a stakeholder says something to you, assuming you know what they are talking about, stop them and politely ask “I’m sorry, I’m not sure I follow. Can you explain that again? I want to make sure I understand.” Similarly, if your stakeholder asks you to build them a solution, take the time to ask the “5 Whys”. You don’t need to literally ask “why” 5 times, but the idea is that the more you probe a request, the more you will uncover the true underlying need. Let me be super clear — you need to find ways to do this such that you are seen as “curious and helpful” and not “difficult”. It’s a delicate balance to be sure, but trust me on this…you will be amazed at how often you think you know something, until you dig a little deeper.
Let me come clean about something real quick…I LOVE process. Probably (definitely) too much. So please bear with me as I opine for a moment.
As a Product Manager, it often feels like you are trying to navigate a ship through treacherous, eel-infested waters, in a thick fog, while blindfolded and tied to the mast. So much of the work we do carries with it SO much ambiguity, and even the most experienced PMs can get quickly “lost at sea” amidst a particularly hairy problem/solution. This is why it is so very important to ground your work in a product development process/framework.
If you are just getting started, or feel like your process/framework needs an overhaul, please take a moment to read through the (highly tactical) article below. The framework I outline in the article is one I created after many hours of work, and it has helped many product managers “remove the blindfold”👇👇👇
So to start with you simply need to have a process, but from there you also need to treat this process LIKE a product. This means that you constantly look to improve and iterate. The framework I shared above is one that came out of many iterations, and in 3 months it will likely be out of date again. Make sure your team uses a common framework (as common language is very important for a product team), and spend some of your time as a team each month talking about process, and what should be changed/improved.
Maybe (probably) it’s because I am not confident enough in my ability to think through all the metrics we should be analyzing for our products/features, but I cannot tell you how often I am going back to my scorecards/dashboards, and asking myself “what am I missing?” or “Is this the right definition of this metric?”. Tracking a product’s 360 degree performance is hard, and it doesn’t just happen after two meetings with your in-house data science team. Someone has to be looking at your metrics on a daily and weekly basis, and there’s a good chance if you aren’t, no one else is.
Someone has to be looking at your metrics on a daily and weekly basis, and there’s a good chance if you aren’t, no one else is.
The reality is that outside the doors of your company/team there are other really smart, driven digital product teams that are producing really cool competitive products as well as technologies that your team could be leveraging. Give yourself 15 minutes each morning to read through the news headlines for your industry, updates from competitors, and articles about technology in general to get a feel for where tech is going in the wider market. IoT, VR/AR, AIML — none of these technologies had the traction today that they had 10 years ago, but the writing was on the wall back then, and smart companies that managed to leverage these technologies early on to solve their customer problems in unique ways are now reaping the benefits.
Here’s a simple truth: your software devs and designers will do a better job if they are empowered to think about customer problems early in the product lifecycle as opposed to receiving a list of JIRA tickets two days before a sprint starts. It’s not my opinion — it’s a proven fact, evidenced by the top tech companies in the world that follow this same pattern. This one is so stupid simple: just invite them into the conversation. Invite them to meetings, chat with them in team ceremonies about work that is coming up, bring them into story mapping sessions, etc. I’ve linked two other articles below on this topic that have helped many a PM “unlock” their team’s full potential.
You made it. Number 10. Let’s land this plane with arguably the most important one on the list:
Burn out is real. If you are working 12 hour days, and missing out on your family life because you “just have too much work to do”, you or your team is doing something wrong. Maybe you need to hire more PMs. Maybe you need to be more ruthless about your calendar/task management. Yes, this is a demanding job. Yes, you will probably work more than a typical 9–5, but if you are not protecting your personal “outside of work” time, you will get burned out and your team, business and customers will suffer. Put the mouse down at 6, find a place to wrap your work, and pick it up the next day. Sure, you will have launch days/weeks where you HAVE to burn the midnight oil. But if you find that in general you are always at work — make a change.
Burn out is real. If you are working 12 hour days, and missing out on your family life because you “just have too much work to do”, you or your team is doing something wrong.