Like any other manager of a functional group, the product development manager wears many hats. He or she is a technical lead, a head coach, a Gantt meister, an HR specialist, a product architect, a social chair, a strategist, a tactical guerilla fighter, a human shield against distractions, a cheer leader, a measurer and communicator of team performance (whether good or bad), a translator of corporate strategy to his/her team, and a translator of technical jabberwocky to less technical stakeholders.

He/she must take care of his/her product as well as people. He/she must work effectively with product management, sales, marketing, manufacturing (for hardware products), finance and operations to ensure the output of the development team plugs into a viable and implementable company plan.

How do you measure the performance of the development manager? Which aspects are the most important to watch?

There is no right answer to this question because the hat prioritization depends on the organization, the state of the product development process, the personal dynamics inside and outside the development team, and the personality and style of the development manager.

For me, under most circumstances, the success of my team defines my own success. There are two areas to watch:

Team performance: Is the team hitting its milestones on execution and developing a great product effectively and efficiently?

Team development: Are we nurturing and empowering team members to grow and prosper in their respective careers?

Team Performance
The greatest compliment anyone can give me and my team is to tell us that we are an execution machine. A team that performs well and executes its initiatives is a team that shines.

Now how do you create conditions to help your team excel? First and foremost, the right people must be in the right jobs. There’s no way to get excellent performance out of an organization if people don’t have the right aptitude and training to do the job they are asked to do in the time frame that the job needs to be done. Performance will also suffer if people are made to do things they don’t like to do for extended periods of time.

Second, we must clearly define goals and objectives, and then stick to them for long enough so the team has a chance to execute against those goals. To be in a startup is to be in flux. New data and learnings flow in all the time and we do need to be able to stay nimble and pivot rapidly when the data tells us to do so. That said, continuous thrashing is the best way to trash a team’s performance and morale. We must strike a balance between our desire to turn on a dime and our need to stay focused so we can execute against the best available information, creating deliverables that will help us test and learn for the next iteration.

Lastly, we need to succinctly define success in a clear and tangible way, then measure the team’s performance against these success metrics. What you can measure you can improve. There is nothing more motivating than being able to celebrate victories when we hit our milestones. And when we miss, those are learning moments that give us valuable data to help improve our performance the next go-around.

Team Development
The second thing to watch for is whether team members feel happy and supported in their jobs, and whether they are growing and prospering along their chosen career paths.

I take the coaching aspect of a development manager’s responsibility very seriously. To the extent possible, the development organization should provide opportunities for team members to learn new things and stretch their skills in their areas of interest.

While I believe the primary characteristic of a high caliber development team is its performance, a happy, motivated team in a trusted, supportive work environment that looks out for their interests and takes steps to help them grow can usually get more work done faster and with a better quality of output.

What do you think about all this? How would you prioritize these hats in your own role?

I have mixed feelings about mobile products from Apple. On the one hand, they are gorgeous. The hardware is well designed and manufactured, the software interface is fabulous, and the user experience simply delights. On the other hand, they are made by Apple, and I have a serious problem with their business practices.

Apple’s closed ecosystem completely turns me off. But it’s the experience of doing business with Apple on behalf of a previous employer that has permanently soured my ability to truly enjoy Apple products. To this day I cannot look at an iPhone or an iPad and not get flashbacks.

This is why I carry an AT&T Samsung Captivate running Android 2.2 (Froyo), and conduct all my business using Google apps on my phone. Samsung and Google are two brands that I dig. I find Samsung to be almost as good as Apple in hardware product design. Their mobile business unit is highly innovative and the Galaxy and Galaxy II lines are fantastic. The cosmetics, fit and finish of their phones are impeccable. I like their oversaturated displays – even my friends who are die-hard Apple fans have had to concede that the 4″ AMOLED display on my phone is more vibrant than their iPhone 4 display. And It’s Not Apple.

As for Google, I can’t exactly remember life before Google Apps. Even my grocery shopping lists are kept as a Google Doc. And That’s Not Apple, either.

This personal hangup explains why I did not get an iPad2 the minute I decided I needed a tablet device. Instead I spent weeks researching available choices: Acer Iconia? Asus Transformer? Motorola Xoom? … etc.

I ended up convincing myself that the Samsung Galaxy Tablet 10.1″ would be the right choice for me. This thing looks breathtakingly on paper. It’s the same size and weight as the iPad2 (thinner and lighter by a hair – not a meaningful differentiator), but it’s not made by Apple.

So I eagerly waited for the device to come available at my neighborhood Best Buy on Friday 6-17-2011. I ran to the store on Saturday in order to play with one, benchmark my experience against the iPad2, then buy the Samsung tab. I thought it was a shoo-in.

Instead, I found that the device was stunning in every hardware detail… but (GASP AND ALAS) I liked the iOS experience on the iPad2 far better than the Android Honeycomb 3.1 experience on the Samsung Galaxy Tab. Honeycomb is a fine OS, but it doesn’t hold up a candle to the usability of iOS 4. And we’ve all read about the wonderful advances in iOS5, coming soon to an Apple device near you. So I went home depressed… and ordered an iPad2 on line.

If ever there is a cautionary tale about the fickle nature of brand loyalty, this is it. I really, really wanted to get an Android tablet, made by Samsung. But in the end, the better product won.

Moral of the story: invest in the user experience. Make it delight the end users. It will pay off in the end.

My approach to product development revolves around user-centered design. The basic tenet of this philosophy is that the product team must be equipped with a thorough understanding of the end user’s needs, wants, expectations and limitations in order to create an excellent product solution to solve the user’s problems.

This understanding begins with user personas at a high level and becomes fleshed out via use cases and user stories. The UX design team can then ideate on a solution to the problems the user is trying to solve and create storyboards to imagine how the solution may be implemented in the context of the product.

The words “use case”, “user story” and “storyboard” can mean different things to different people. This is what I mean when I use these words to describe the tools and artifacts I use in the product design process.

Use case: A high level thought experiment of a workflow from a user’s perspective.

User story: A brief description of a part of a use case or storyboard that succinctly defines a task the user has to complete, from the user’s perspective, with no assumptions placed on design or implementation. Used to describe functionality that will go into a backlog to be prioritized and managed by a product owner (in classic Agile methodology) It is usually much more granular than a use case and describes a snippet of what the user needs to do to complete a workflow.

Storyboard: An output of the design process that illustrates the experience of the user in a journey to complete a workflow using the product. In my experience, this is the fastest and most effective way to turn a high level UX idea into something concrete that the product management team can use to test with customers and the product development team can use to plan their work.

I find that these three things are fairly universal in their applicability to all kinds of products, hardware and software alike. In cases where the use cases are complex and the solution is non-obvious, it is vastly faster and cheaper to iterate a design idea at the storyboard level than to code it up and then review the actual working code output.

With the right talent on the task, one can literally come up with 5 or 6 storyboard iterations in a single day without investing in any engineering development. The impact on software products is substantial – it can take weeks to program just one of those iterations, so storyboards saves time and money in a tangible manner. The impact on hardware products is game changing – a single iteration for a hardware implementation could take months or longer. Storyboards allow the product team to iterate, test and learn, so that we can come up with a better end result in a shorter period of time with the least possible investment in engineering development.

Once the product design is vetted at the storyboard level, it becomes much easier to fill the rest of the design gap with a detailed design solution, and development will then be able to implement the design efficiently and effectively.