Product Management: Micro Focus

In the previous post I talked about clearly defining a product and communicating the definition to the whole team.

Once you have your product definition in place, there are two things that you control that can increase your chances to succeed:

1. Quality of the team
2. How well the work is aligned with the goals

We’re into product management, so now I’ll talk about Micro Focus, which is making sure that the everyday work of the whole team is actually promoting the stated goal of the company.

Micro Focus

No matter how hard you try, you’re going to have some “alignment inefficiency” - people working on something that doesn’t 100% help the goal. You are trying to minimize that. There are two reasons why this inefficiency exists:
First, most of the work (at least in the early, product development stage of the startup) is around details. The job of the programmer is very details intensive: you have to juggle a ton of various bits of knowledge in your head at the same time, while solving a very narrow problem in a very exact and accurate way. It is next to impossible to keep the “big picture” in your head the whole time. This is why pair programming proves so effective and why sometimes a seemingly “obvious” bug escapes the programmer’s attention.

Second, many of jobs that are likely to exist on your team have a universal and natural tendency to focus on things that aren’t helping your goal. For example:

1. Programmers tend to over-engineer and over-do features because it’s often challenging, fun and speaks to their inner perfectionism. This is widely known as “gold plating”.
2. Testers tend to concentrate on edge cases because their experience taught them this is where lots of nasty bugs go hiding.

The product manager is in a good position to not be distracted by all the above. “Attention to detail” is probably not a common strength with product managers anyway :)
Here are a few practical methods to improve Micro Focus:

1. Communicate the focus clearly for every task. If you’re writing requirement documents that programmers work with - don’t just detail the specifics of the requirement. Describe the exact motivation and focus of what this task is trying to achieve. Instead of just saying “we need to have a search box” also say “we’re trying to allow people to easily find popular products based on brand, not based on exact model number”.
2. Pay attention to the tendencies I mentioned above. Instead of saying “we’ll allow signing up using Facebook or Twitter” also mention that “there’s no special treatment of a user who signed up for our service then deleted her Facebook account” (for QA) and “there’s no need to allow merging two accounts of the same user” (for the gold-plating programmer).
3. Have a moment in time where you talk face-to-face with the other team members and clearly explain what you’re trying to achieve, answer questions and think about the task together. A 15 minute chat with the developers and testers before starting a task can go a great way.
4. Know what people are working on: walk the halls and enter some rooms. Show up at the DSM. Ask questions.
5. Get to know the people. Different team members understand things differently, have different experiences and tendencies. Once you learn that, you know what and how much you should communicate to each.

Why Me?

So should the product manager be doing all this Micro Focusing? What’s with the team leaders? RND manager? CEO?
Of course you’re right. These people should be doing a lot of Micro Focusing, but believe it or not, the product manager is better positioned to do so.
Team leaders and RND manager - yes, they usually have a better ability to look at the bigger picture (that’s why they got “promoted” out of their cushy development job in the first place) but they have a very specific, detail-oriented job to do too: they need to manage people and tasks, think about resources, make execution efficient, develop process, take care of loose ends. They are trying to take a feature and make it happen as fast and well as possible. They can’t be thinking at every step of the way “am I doing the right thing?”. They just think “am I doing this thing in the best possible way?”
The CEO also has disadvantages: she needs to take care of things beyond the product. She may be a bit more distant from the day-to-day work. She may be in a different time zone, selling the product or looking for funding. She can definitely tell you whether you’re working on the right thing or not, but she just can’t be there in time to tell you that.

My company builds Delver - a website where you can discover great products that are interesting to you with the help of your friends. Check it out!