Have you ever considered that being end goal focused could impede your growth?
It can and here is my method to address it.
I am sure I wrote about Deep Dive before. It’s such a useful approach and one that is crucial to prepare the business for the next growth phase.
If you have ever managed a team, I am sure you did your fair amount of micro-managing – especially when things are not going in the right direction. Diving deep prevents. micromanaging. It lets you see and do tasks from the key employee standpoint rather than that of a Manager. This way you uncover weak spots of your business, faster and in a more productive way than shadowing your team. It helps retain talent, but effectively through avoidance of micromanagement.
It’s also part of the emphatic management style and user experience. It assumes that we are all goal focused and we are always looking for the fastest and easiest way from A to B. Both users, team members and managers.
There is no better way to understand the shortcuts and workarounds than doing it yourself.
By doing the work you will very quickly understand the motives of your team and your users’ pain points, their worries and frustrations as well as the most important wow factors and aha moments.
User experience is just that. Collection of experiences: The good and bad. Our job as product managers is to aim for only Good and if not remove entirely, do our best to neutralise the Bad.
I recommend doing a deep dive, when you think everything is going great. The moment you are ready for scale, the team is ready, processes are tight, tech works great – now it’s time to scale!
Wait.
It’s actually time for the Deep Dive to test the waters. In the case of the scale up – the Captain (or the Product Manager) checks the waters and pushes the boat out.
What does it mean in practice?
As a leader, you take on the role of the key employee – A Growth hacker, Sales Manager, Customer Success or Head of Marketing. You start by finding your own account and take it through a full journey from the lead all the way to the delivery. It has to be a new account, developed entirely by you, to ensure there is no previous experience.
How do you feel? All works great? Can you do 10? Or 100?
The rules are simple: No shadowing, no delegating and most importantly you follow all the rules you have set for your team: Rigidly. Any workaround, shortcut you have to take, any time you use your knowledge to get from A – B – take a note and report back.
The most important elements of this exercise are:
- funnel
- daily weekly check ins/
- and a PowerPoint with screenshots listing out all the stumble blocks/ potential for improvement
You take notes and report back to your team. If you reach a stumble block consult their experience, take notes and report back. All the time recording how you feel completing that step. You will be amazed how much they will share, when you are the one struggling.
Can’t your team do that?
The short answer is yes. But the long answer is a topic for another blog post. If you are employing a result focused team, they will find workarounds. They will just get on with it. Only by doing it yourself can you appreciate why certain processes are not followed and why some of the functionalities are not being used.
Because the reality is that we want results and positive attitude and this is what gets rewarded on the daily basis.
Positive attitude leaves very little room for honest, lay-it-bare feedback. Feedback is hard work and it is unrewarding, which is why it’s the Product Managers role to do the Deep Dive to find out.
I remembered, back in the day, when I worked as a Sales Manager we had implemented a few very expensive systems that were supposed to make the sales team’s job easier.
In reality it meant we had to stay after hours to input the data or catch up on all the work that had to be done. None of those extra hours brought extra additional results. What happens if the result focused team doesn’t see more results for more effort?
You guessed it. They leave. So do users. Every task the user takes, must deliver value. As a product manager it is your job to make sure that is the case.
Otherwise you may have to do it for them and analyse how scalable it is.
So what happened in my old job? Indeed soon after implementation of the systems that didn’t make our job easier, many people left.
It didn’t go unnoticed. Soon after a team assistant was employed whose job was solely to input data into systems was hired, freeing the all important time for sales.
But the damage has been done. Building on that experience I now like to experience the frustration before my team or my users. Just because something works from the engineering perspective it doesn’t mean it’s fun to use.
