Accountability and Scrum

So this blog post is all about the core question of who is accountable for the team's execution of its sprint commitment.

We all know that "product owners" are the single wringable neck for the backlog. He/She makes the final call regarding the prioritization of the work for the team. The Scrum Master is responsible for making sure the team is following Agile\Scrum best practices especially at daily scrum, sprint review, and sprint retrospective.

This core question of execution responsibility is especially complicated because:

• Teams are often cross functional (developers, QA, UX, etc.) and each individual has their own functional manager. You can't make the functional managers responsible for the team's performance since there are likely several of them.
• I struggle with suggesting that the scrum master be responsible for the teams commitment as he/she may not have the authority in the organizational strcuture.

So now that we have discussed the question, let's discuss a possible solution. My suggestion is simple:

• Make everyone on the team except the Product Owner report into a single manager. That manager is responsible for the performance of all the team members. Since the performance of the individuals of the team are directly tied to the body of work the team commits to and the execution of that work, he/she is responsible for the team's execution.

What are your thoughts...let me know who you think is responsible for the team's execution...

Agile Product Management

So I've attended both ProductCamps here in RTP, NC. During our most recent one, I presented "Agile Product Management". The presentation can be found here which is on my website : www.peterghali.org.

A couple of key points:

• Scrum\Agile really misunderstand the role of product management and try to box it in to this "Product Owner" role. Unfortunately, you can't fit a square peg in a round hole...there are some struggles.
• Product Manager who are also SCRUM "product owners" will struggle trying to embed themselves in SCRUM while also being the market expert that executives expect them to be.
• When giving the presentation I tried to focus on introducing the problem and then presenting techniques and open discussion on how folks can solve the problem.
  

The presentation also covers several techniques for feature prioritization that were presented at the most recent Agile 2009 conference (with proper credit given).

The following quotation from Bob Galen's Scrum Product Ownership book says it all : "No wonder we have tension in the agile community where we have Product Owners who are struggling to balance their roles against organizational Product Management expectations"

Let me know what you think!

Changing your Sprint Length

So we recently undertook an "experiment" to switch our sprint length from 2 weeks to 1 week. This was due to a high priority project that needed some extra visibility and ability to "course correct" if something came up.

Here are some things to keep your eye on if you decide to reduce your sprint length:

• Meeting Overhead - You are now doing your sprint planning, review, and retrospective more often. While some may say that these meetings need should be reduced in length, the reality on the ground is that the shift in sprint length causes enough of a change where the meetings will likely take the same amount of time.
• Product Owner Time frames - With a two week sprint you get 2 backlog grooming sessions before the next sprint starts. That allows you more than enough time to get the backlog estimated and in order to ensure a smooth sprint planning. With only 1 backlog grooming session, the churn is constant and its harder to stay ahead of the team. Remember if the team decides to quickly move in another direction, you also have to keep your management aware of the changes.
  
• Work Size - The team is quite used to 2 week sprints. There is a comfort level with the size and estimate of the work. With 1 week sprints you can easily find it difficult to know the right amount of work to take on.
• External Tasks - A 1 day vacation or an illness of a team member because material. All day meetings or long 2-4 hour meetings become material and difficult to manage. Don't forget to plan accordingly.

Be mindful and aware...if you know these "gotchas" ahead of time you can prepare and mitigate accordingly.

When the Product Owner has to say no

I read the following blog post "When the Product Owner has to say no". Intriguing but I could resist the urge to comment.

The scenarios where Product Owner has to say no in the blog post were quite true. To me, the Product Owner has to be able to say no and sometimes make those difficult trade-offs between which customer or internal stakeholder gets what they are asking for and which ones have to wait. Until you've had to sit in front of a VP and explain those trade-offs and why that VP didn't get what they needed, you haven't earned your chops as a Product Owner.

Here's what I take issue with the conclusion: "Many NOs accumulated in the course of a project are a symptom of a failure in the PO performance." While I have no problem taking responsibility for my actions and learning from them. I do think this type of broad generalization leaves out of a lot of key facts:

1. Sometimes the Product Owner has to say no to an internal stakeholder in order to keep the team focused on its goals and commitments. This is not due to a failure in PO performance, but rather a lack of focus from other folks
2. The Product Owner is part of the team. While some may say that they are the single "wringable" neck, I'd like to think that the team can self-manage to prevent these types of unwarranted behaviors.
3. Part of the role of the Scrum master is make sure that the team is acting agile and following scrum practices. Many of the issues noted by the author of the blog post indicate a lack of leadership on the part of the scrum master.

I'm all about taking responsibility, but I'm not about the "blame the product owner" for everything mentality.

A Follow-up from Last week

So last week I shared with you that I read Strengths Finder, but I didn't share my specific strengths. So here they are:

• Restorative - Chances are good that you are mentally quick and highly resourceful. You constantly consider how you can upgrade all sorts of things in your personal or professional life. You eagerly seek and find opportunities to better yourself.
• Achiever - It’s very likely that you work industriously to finish all your daily assignments. You derive a great deal of satisfaction from reaching goals others have set for you. Meeting their expectations for the day undoubtedly is one of your top priorities.
• Harmony - Because of your strengths, you long to attain mental and emotional steadiness in your personal and professional life. For this reason, you prefer to perform all the tasks assigned to you each day.
• Learner - By nature, you frequently examine the factors leading up to an event. Therein you discover the reasons why things happened the way they did. A number of individuals and/or groups probably appreciate your logical thinking style.
• Context - By nature, you are quite intrigued by history’s significant events and people. Instinctively, you may examine certain kinds of circumstances, opportunities, or problems.
  

The best thing I read this weekend

So, I read "Strengths Based Leadership" and took their assessment this weekend. It was a pleasant read and has tidbits of information that were insightful. It found was that there are no series of traits or strengths that all leaders typically possess. Rather, is it identifying your strengths and building a team around you that will complement (not compliment) them. It goes through 4 case studies of corporate leaders and how their differing strengths were utilized to lead them and their companies to success. While this was a bit intriguing, it was NOT the best thing I read this weekend.

The best thing I read this weekend was a 1 page article in BusinessWeek. It is titled "The Best Leadership is Good Management (click here). Can you lead and manage at the same time? This reminded me of MBWA (Management By Walking Around). It is a great technique for talking to folks, developing trust, mentoring and guiding, and of course, managing!

On the Origins of Agile

So, as a practicing Agile Product Owner, with a more traditional product management background I decided to dig a bit deeper into original "founding fathers" of agile to understand their backgrounds. I've done some digging around and you can see the details below. All of the "founding fathers" of agile had a generally homogenous background founded in technical disciplines such as engineering, computer science, and physics. We all know that when you have homegenous teams, the results you tend to get are not as strong as those teams that are more diverse. I'm curious to know if agile manifesto and agile principles/techniques could be improved by revisiting them from a more cross functional perspective. We all know it takes more that developers to deliver software!

What are your thoughts?

Here is some of the research I did to review their backgrounds. While I realize I cannot encompass the full breadth of their experiences, you get the idea...

• Mike Beedle - Technical Background - PhD in Physics and he has published in several areas including object technology, patterns, components, frameworks, software development, programming languages, reusability, workflow, BPR, and Physics.
• Arie van Bennekum - Technical Background - Started his career as a developer and he has a IT education.
• Alistair Cockburn - Technical Background - B.S. and M.S. in Computer Science with a PhD. He has been a hardware designer and research staff member.
• Ward Cunningham - Technical Background - He has also served as Director of R&D at Wyatt Software and as Principle Engineer in the Tektronix Computer Research Laboratory before that.
• Martin Fowler - Technical Background - He started working with software in the early 80's and in the mid 80's I started getting interested in the then new world of object-oriented development. I started to specialize in bringing objects to business information systems, first with a couple of companies and then as an independent consultant. In the early days this was using Smalltalk and C++, now it's Java, C# and Ruby.
• Jim Highsmith - Technical Background - He has held technical and management positions with software, computer hardware, banking and energy companies. He has a B.S. in Electrical Engineering and an M.S. in Management
• Andrew Hunt - Technical Background - Andy has been writing software professionally since the early 80's across diverse industries such as telecommunications, banking, financial services, utilities, medical imaging, graphic arts, and Internet services.
• Ron Jeffries - Technical Background - Ron has been a systems developer for more years than most of you have been alive, and his teams have built operating systems, compilers, relational database systems, and a wide range of applications.
• Jon Kern - Technical Background - Degree in engineering. Held positions such as Director of QA, Software Architect, etc.
• Brian Marick - Technical Background - B.S. Math and M.S. in Computer Science. Lots of experience as a programmer and tester.
  
• There are more, but you get the idea...
  

Test Driven Development is not the same as agile!

So I was reading a recent blog post on this issue here. Here are a couple of key lines that really struck a chord with me:

• Over the last several years managers, directors, and executives have asked me to present empirical evidence that Agile will cost them less money and take less time

This is a great question. I'm interested in data from the community?

• A recent paper (here) published by Microsoft and IBM, showed that practicing TDD versus general unit testing reduced bug density by 40-90%. Reading this paper gave me one data point; bugs are one of the three things listed above that customers hate the most. The question is can bugs be equated to time and money?

This is really insightful and would suggest a renewed focus on eliminating bugs to reduce cost. But the author fails to include which is listed in the white paper is the associated cost of TDD. Here are the costs as noted by the paper "Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD." Despite the increase in additional development time, TDD is worth it as the costs of fixing issues post-customer launch is very high.

Overall the author of the blog has the right idea, that TDD is the way to go! However, he seems to conflate agile and Test Driven Development. They are two distinct things. One can practice agile and not TDD and vice versa. Now we can debate whether or not you should write unit tests for "private" methods :)

Benefits of Agile Software Development

Agile Software development is well documented all over the place. You can see the agile manifesto here. I'm not going to expound on all the details that already all over the place, rather I'm going to focus on the benefits that I have seen in practice. Enough of this theory and explanation of how agile would ideally work, here's the real scoop. There are some drawbacks of Agile and other benefits, more on that later.

1. Customer's change their minds and that is ok - The burden on trying to know every single detail of the customer/market requirements is greatly reduced. I have never worked in an organization where there were enough product managers to do everything that product managers are supposed to do. Having to write complicated and detailed technical requirements up front before development begins was always a huge burden. I hate being on the critical path. With Agile, I don't have to know every detail up front, I can accept the fact that the customer can see the product and change their mind.
2. Estimating work is much better in Agile - I love the concept of story points and velocity. It let's the team achieve a natural capacity and work speed rather than trying to work overtime to achieve an unrealistic deadline because the product manager took too long writing the requirements.
3. Team work is really emphasized - This is the real strength of Agile. Teams work together, teams communicate daily, teams communicate verbally. It just works well rather than just trying to throw "artifacts" over the fence to the development team.
   

The best advice I ever got

I read this recent article in Fortune (here) and wanted to share with folks. It contains interviews with several well known business leaders in which they share the best advice they ever received. I typically enjoy these types of articles as they allow us to "peak" into these personas to see what makes them tick. While I'm not in the same league as those folks, I did want to share some advice I've received that I'll never forget.

I used to work for a fellow by the name of Alex Bloom (now CEO of Handango) and he told me one time that "Results matter". I know this seem quite obvious, but often times folks jump into a situation without thinking of they can truly deliver results. It has to be tangible and deliver business value. So think about this before you accept your next project. No one jumps into a pool before checking to see if there is any water.

Another piece of advice I'd like to share with folks is "Always be prepared". Everytime I walk into a meeting I want to know my audience and be the most knowledgable person in the room. Everytime I ask a question, I want to have a good handle on the answer before I ask it. Everytime I prepare a presentation I want to know my audience and anticipate their questions. I always get a warm fuzzy feeling when a person in the audience asks a question during a presentation and I respond with "Great Question, I've answered it on the next slide".

Theory vs. Reality

When I got my MBA and they taught me about organizational culture, motivation, compensation, etc., I formed this ideal image of HR as playing a critical role in fostering an intangible resource (people) through all of the many things that HR can do. I thought to myself...this is how it should be!

But one step into reality has taught me that theory and practice are not quite one and the same. In reality, I've worked at companies where HR focused strictly on dealing with compensation and was nothing more than a blunt tool to be used when costs needed to be cut. I've also worked at one place where HR reported into the CFO. I thought to myself what message does that send to folks?

So I got to thinking, why is there such a disparity between what is taught in the classroom and the reality that I see. Then the answer hit me! The professors that teach these courses are rarely industry HR veterans, rather they are PhDs who get "real world" experience when they get hired as consultants to fix companies problems. So essentially I'm getting a consultant's perspective. How many of us have ever had a great experience with a consultant?

A Thought regarding a recent CrankyPM post

So I was reading this post from the CrankyPM regarding real estate postings that don't have enough information. A bad example of Product Marketing she says. I did some homework of my own to see if I got the same results she did. I did. The CrankyPM was quite disappointed.

The purpose of these ads is not to answer the three questions she noted:

1. Where is the home?
   
2. Is the home big enough for my family?
   
3. What’s the asking price?

What if the ad had all those things, but didn't have a picture. I'm willing to bet that fewer people would call than if there was picture, but the ad didn't answer all 3 of those questions. Buying a home is an emotional decision. People like to see the home and ask themselves "Can I see myself living there?". If the answer is "Yes" then the person will likely pick up the phone and call.

So at the end of the day, I disagree...the purpose of the ad is to get you to talk to the real estate agent. The ad serves its purpose and is designed to elicit an emotional response. It reminds me that the purpose of a resume to not to get you the job, but rather to get you the interview.

Any thoughts?

Product Manager = Generalist

So there was one point in my career, while walking through the break room I noticed several job listings. There was one in marketing, one in finance, one in development, a sales engineer, and one in quality assurance. I read through each one and I realized that I could do significant parts of all of the other jobs. At that point, I realized that as a product managers we are generalists. We need to be able to effectively communicate with literally every functional group in the organization to represent our products effectively. Everyone in the organization either doesn't know what Product Management does or only can only tell you the part of Product Management that interfaces with their team. As a result, no one person knows the entire set of all of the responsibilities of a product manager, except the product manager themselves.

This is probably the reason that Product Management location in company org chart varies widely from company to company. In technology dominated company (i.e. where the technology team dominates mindshare), the Product Management team falls under the VP of Engineering or the CTO, etc. In this type of org, they are primarily focused on supporting the needs of engineering such as requirements, etc.

In other companies, Product Management falls under the VP of marketing where they take a more market centric view. This involves product marketing assistance, market research, and competitive analysis. In this org, you see more market requirements than product requirements.

Pragmatic Marketing has a whole eBook on Product Management here.

Agile Roadmapping and Pragmatic Marketing

Today I attended the "Agile Roadmapping" webinar helded by Pragmatic Marketing. The folks at Pragmatic Marketing are top notch and I have enjoyed their classes and have become "Pragmatic Marketing Certified". Enough about me...the webinar was a total disappointment. The sound cut off and they spent most of the time talking about their travels. It got way off topic and it just glossed over the day to day struggles that product managers face developing roadmaps in an agile environment. So I've decided to dedicate this blogpost to providing my viewpoint and perspective in an effort to dig a bit deeper than the superficial.

The challenges:

• Setting Expectations - With agile your roadmap is very detailed during the current sprint and then becomes less so as you start to prioritize your product backlog. As for putting when items will be delivered, I would recommend only putting a timef rame down for the current sprint stories and then just putting the rest down in a priority. If executives don't like the fact that there is no time frame for that feature they want by the end of the year, work to educate them that scrum is the not the right process to guarantee delivery of a feature many sprints from now. Careful positioning of the roadmap is critical in the context of SCRUM.
• Crafting - A roadmap is an excellent communication tool for the vision of product management. Priorities, product themes, and overall initiatives can be communicated along with their value to the market. It must be updated often, preferably at the end of the every sprint as you learn more and have begun planning for the next sprint. An updated roadmap presentation including goals for the current sprint and how that fits into the remaining work for that particular feature or product. How many times have you had to scurry to update your presentation when you get an email from an exec who wants an update? If you updated it at the end of every sprint, it would be an easy request to meet.
• Time - Many times we are so busy being product owners and getting our heads around all of the incoming stories that we can't even begin to think about the market. Take time to get this done. Step away from the tactical a little bit...your team will appreciate it in the long run.

What are your thoughts?

Using Social Media

Good Discussion on Social Media and Business to Business interactions.

• Social Media is Interaction, Engagement, Conversation, Relationships, not about Tools!
• Recommenders and Purchasers are consumers with expectations
• Social media allows an instantaneous response to serious brand issues. You have to live with the bad parts of social media, but you can choose to live with the good.
• Private twitter accounts? I didn't know that existed! Yammer is similar.
  

ProductCamp RTP - 1110

Product Management - 10 important things we must do:

1. Think - Take time away or you can easily become swallowed into the tactical.
2. Leadership - 90% of your job.
3. Pricing - Product Management should own the pricing of their product. Pricing is the only thing that brings in revenue
4. Measure - Customer Satisfaction, Defects, Costs, etc. Track and share. It's easier to lead when you have the information to lead.
5. Observe - Watch and learn. Observe your customers, determine why, and learn.
6. Define your personas- Who are your buyers vs. users. Know their background, daily activities, etc.
7. Call Reports - Validate assumptions, Discuss new opportunities
8. Manage Roadmaps - Feature vs. Release based, Most important deliverable, review weekly. Make your roadmap, fill it in with key milestones and strategy.
9. Win/Loss Analysis - Helps identify key features. Sales Process problems. Win\Loss analysis will be a career differentiator.
10. Write Problem Statements - Don't just have it in your head.

ProductCamp RTP - 1015

So far I'm liking my first session regarding making sure that product managers understand needs. What are the needs of segmentation models and the individual user, but don't forget the other user personas. Lots of great discussion on innovation vs. market share vs. financial targets, etc.

ProductCamp RTP - 0900

Well I can't believe it, I'm here on time and I'm blogging away. The team of folks organizing the event could not have done a better job. Here's a photo:

ProductCamp RTP

Tomorrow is the big day! I'm looking forward to attending and will be blogging throughout the day. For more information please check it out here! Follow us on twitter as well here.

The Root Cause

Have you ever been in a meeting where developers were talking about what frustrates them? That's a tough meeting to go to. You often hear similar types of complaints:

• The requirements changed at the last minute?
  
• A developer would like to make sure the work he is doing is the right work?

What is the source of all of these "bad smells"? I typically try to dig down to the root of the problem by always asking "Why?" 3 times. So let's give it a shot:

• Why did the requirements change at the last minute? - Some executive swooped in to give their two cents?
• Why did the executive swoop in? Because they thought they knew better
• Why did they think they know better? Because they don't trust the folks they hired to do the right job

Next time you think something smells a bit funny, just ask why 3 times :)

Product Marketing 101

Often times I've seen product marketing material and positioning focus on features of the product. This is the easy first step for technical product managers or engineers to jump right into. You ask an engineer "Why should the customer buy this product?" and the answer you get is "It does A, B, and C"...Let me propose another way

Focus on the customer's problems and needs. Make the marketing about solving their needs, making their pain points disappear. Also keep in mind the audience. Is your buyer or the person you are trying to reach with this content very technical? Do they want to hear detailed specifications or how you are going to make their lives easier?

Here is a good article that I like. Click here.

My "100 day" plan

So I'm starting my new job tomorrow and have been hearing a lot lately about Barack Obama's first 100 days and how he has fared. So I thought to myself, I should consider where I want to be after 100 days on the job and what key milestones do I want to have accomplished. So here we go:

1. I want to be considered as SME regarding my aspects of the product
2. I want to be considered as quite knowledgeable about the entire product set
3. I want to reduce the workload on my manager
4. I want to feel comfortable with the product development process
5. I want to start to build trust with my team

I know that there aren't really specific or measurable, but they are areas where I will be tracking my progress.

Some interesting reading

So the other day I sat down with my friends "Businessweek" and "Fortune" and got two interesting tidbits of information that really resonated with me, so I thought I'd share:

1. From Carol Bartz, CEO of Yahoo! - "Yahoo was amateur hour in the past when it comes to product management..groups haphazardly released things without a clear sense of whether customers wanted them. From now on she has promised, products will arrive on schedule so that customers can offer feedback".
2. From Massimo d'Amore, Pepsi Americas CEO - "Aiming for perfection is the enemy of good progress". This one really struck me...A lot of times I've seen grandiose visions and beautiful powerpoint presentations, but the reality on the ground was that there was no real progress being made. While striving for perfection is important, I'd rather focus on good progress!

Leaving a job

So as many of you have noticed, its been a while since a couple of weeks since I have posted anything. Who am I kidding..."many of you", I doubt that anyone besides me reads this blog...but anyways...The reason why it has been a couple of weeks is that right now I'm between jobs. Leaving a job can be a trying and difficult time, but it says a lot about your character. I've seen employees pretty much say "screw you" and leave. I've seen folks give their two weeks notice, but somehow disappear. I've gone through my fair share of job transitions and here are some lessons I have learned:

1. Be there - Support your team as you transition. They will likely need what is in your head and supporting them will likely leave them with a positive memory of your work. I remember the following quotation quite vividly "A man is not defined by what happens to him, but rather by how he reacts to what happens to him."
2. Be positive - No matter how frustrated or angry you are, focus on the lessons learned and how you can apply those lessons in the future.
3. Give yourself some time off - If your financial situation allows for it, a couple of days, weeks, etc. can allow you to get back to those things you neglected while you were working those long hours. You'll start your new job feeling refreshed and energized.
4. Ask for feedback - Now that folks know you are not sticking around, it may be a good time to ask for candid feedback. This is a good opportunity to learn about how others view you so you can avoid making the same mistakes at your new job.

Every once in a while I like to take a moment and reflect on some key lessons that I have learned. Given that I am transitioning to a new opportunity I thought that this would be a good time to share some thoughts...

Listen
This is an important skill that I see so many managers and leaders lacking. After managing my team for several months I learned that you have to listen to, learn from, and respect everyone you work with. When folks know that you are listening they listen to you as well. Projects and people move forward when they listen.

Manage Knowledge and Information
In a technology company you have to know your product. This can be complex. Set up a wiki, document your knowledge to share with others. This will not only help you learn and grow, but also help your team and others. This can drive sales enablement materials as well.

Know your audience
When you give a presentation think about your audience and the perspectives they have and questions they may have. I'm also a big believer in managing your manager. As an employee it is important to understand your manager's style of communication, likes and dislikes, etc. Leadership is about the ability to influence and you can't influence that which you do not know.

Be Positive
Sometimes its easy to get bogged down in the negative. Focus on the positive. For me, I've focused on what I have learned and how I have grown as a product manager. I am also quite thankful for the opportunities i have been given. Nobody likes to work with a grumpy product manager!

Your success is defined by the success of your team
As a leader and manager of a team, it has always helped me to be a "servant leader" to enable my team's success. I have taken a lot of pride in developing and growing the team to help deliver the best product and product information to market. Allow your team to succeed and your success will follow

Succession Planning is important
I know we typically hear about this for CEOs and other C-level executives...but succession planning for your team? I say yes! If you have done a good job mentoring your team and leading them to success, then this won't be that difficult. I recently transitioned into a new role within my former company and my previous team didn't miss a beat. It feels a bit weird to not feel needed anymore, but I can honestly say I'm proud of that accomplishment.

Transparency in product development
When I started my role running the program and project teams, things were a mess, nobody knew where the projects were in the "process" and nobody knew who was working on what. The first thing I did was put "windows on the factory". We started tracking how our resources were being allocated against our priorities and we defined a simple process that was just enough process for us. We could now track our projects against this process. It wasn't perfection on day one, but it was clearly a step in the right direction.

Some Recent Research

As a North Carolina State University graduate, I still do follow the business school and latest news. Yesterday this came across my inbox:

Studies Show That Nice Guys Finish First in Business World
When it comes to leading a team tasked with developing new products and bringing them to market, new research by faculty at the North Carolina State University College of Management shows that being nice and playing well with others gives you a very real competitive advantage. Read more

So, let me get this straight..a tenured professor at NCSU just figured this out? A junior project manager can tell you that!

Meetings and Laptops

I know that this is a lot of debate about allowing laptops in meetings. Nothing is more annoying tha when someone is typing away and then something comes up and they are asked a question. The deer in the headlights look and then having the repeat the past 2 minutes of conversation are quite wasteful.

When I run a meeting I don't have a particular rule to have all laptops closed. I do, however, prefer to keep my laptop closed when I attend meetings. I find the use of a pad of paper and a pen to take notes and then going back to my desk with my notes is nice...sometimes its nice to not to get away from your laptop.

What do you do?

A lot of times, folks ask me what I do for a living...whenever I say product management, the first thing I hear back is either "What is that?" or "So do you like being a project manager?"

Product management is sort of difficult to define to those outside of the corporate world. I always explain it to folks by saying that a product managers job is to understand the market and work with the team to define a strategy and plan to ensure product success. Sometimes you find that product management reports into marketing, into a technology, or as a stand alone business group.

I also find myself explaining the differences between program, project, and product management to folks. I know I've oversimplified it, but here's my quick and dirty explanation:

• Project - Works to determine when the feature will be released.
• Product - Works to determine what features are important and what the feature is. In some companies the product manger has P&L responsibility.
  
• Program - Across project resource allocation and project coordination. This function can manage one or more project managers for a particular account or product.

Anyways, that enough for today on that little pet peeve :)

Black and White

Earlier in my career I was sort of a black and white type of guy...as I now know, the world is filled with a lot of shades of gray. You'll often have conflict between scope and deadlines or between quality and deadlines, etc where the answer isn't always black and white. As a project manager and product manager I've learned that understanding, quantifying, and minimizing risk through communication with the team is essential. There are two things that have helped me in guiding successful teams and I thought I'd share with you:

• Listening - This cannot be overstated. Even if you disagree with the perspective or opinion, acknowledgment of that opinion goes a long way to building a team consensus. When you listen you might actually learn something.
  
• Be prepared - I have a rule that I work to be prepared for meetings. Being prepared allows you to actually know what you are talking about and you can't lead a team if the team doesn't believe you know what you are saying. Take the extra time to prepare for meetings, review the agenda, talk to the key players. Knowledge is very helpful in decision making :)

Pricing - The difficulties

If you have ever worked at a small company interested in becoming more profitable, you've surely faced the difficulties of pricing your product. Many product manager typically fall into the trap of pricing by taking the product's cost to deploy (including a corporate overhead) and adding a markup. There are several reasons why this type of pricing is typically the easiest to rely on:

1. It's the easiest to determine since costs can easily be determined.
   
2. It requires the least amount of effort. See Reason #1
   
3. It's supposed to lead to profitability
   

While this may work, it is clearly not the most ideal way to price your product. There are also a lot of factors in pricing such as goals (market share vs. profitability) and also your product's strength in the market.

The Roadmap Responsibility

At one point in my career I worked at a start up technology company who was really interested in getting that next sale, that next logo that they can put in their sales pitches and investor presentations. So of course the product managers scurry revising and creating their roadmaps and putting dates and milestones, etc. It's easy to put together a roadmap, as product managers we know the market, the customers, and the competition. What's hard is to put together a credible roadmap.

We have all seen roadmaps that we look back on a year later and just wonder "What happened to all of those plans and ideas?" It was likely because we didn't get real buy in and commitment. When that happens the road map just becomes a slide that some product manager created. There is no sense of true partnership or responsibility on the part of the team for delivery.

So here are a couple of tips that I have found helpful:

1. If you don't have buy in from the whole team, don't put dates or even quarters in your roadmap. When the sales team shows this roadmap they are going to get asked "When will you release feature ABC?". The answer is simple, this is a plan and we are working planning the release of that feature and we will let you know as soon as we have feature ABC committed for delivery. Be honest and truthful with clients, it will pay off.
2. Create the intial draft of the roadmap with everyone's input. It's easy for a product manager to go off and do all of this research and present a road map to the team. A better way to do that is to go to engineering and ask them for what improvements do they want to see. Perhaps there are infrastructure improvements that can make the support teams work a lot easier. Maybe some internal tools to debug issues to lower the cost of customer service. There are a lot of ideas, include everyone!
3. Make sure you have a product development process that provides clarity and transparency into how resources are being allocated and how the roadmap will get implemented. As a product manager you will get graded on what gets implemented, not what you define or want.
   

Just some initial thoughts on such a difficult subject. Obviously there is more to it than just this blog post, but these are helpful lessons I've learned.

Crossing the Chasm

Recently this book was being discussed and I decided it was time for me to understand this "chasm" a bit more. I picked up the book from Amazon (I love Amazon!) and read through it and took notes. Finished it up in about a week. I would definitely recommend this book to technology product managers and marketing professionals. It focuses on the product marketing and positioning for determining a target market and what it takes to get your products across the "chasm" of early adopters into the early majority. Here's a good summary.

You can learn more about this great book on Wikipedia - Crossing the Chasm

Building trust with your team

Even though I come from an engineering background with almost 10 years of experience in all sorts of large and small companies, it was a lot harder than I thought to transition into a product management role. As an engineer, I always thought that "business team" didn't really do anything and that engineering was where the tire hits the road! Now that years have passed and I'm on the other side of that artificially created opposition, I've gained a deeper appreciation for how teams can work together to build great products.

One of my first lessons as a product manager involved forming a relationship with engineering built on trust that was mutually beneficial. Easier said than done! Here are some of the lessons I learned early on to help:

1. Give Credit - It is NEVER about you. It's about the team! Take every chance you get to put the spotlight on them.
   
2. Be Reasonable - As a product manager you have to balance between the sales and marketing teams who say "If you don't ask for it, you'll never get it" and the engineers who say "That's impossible to develop". Challenge and learn, maybe there is a phased approached and not every feature is a P1 feature.
3. Establish yourself as a credible market represenative - Do your homework! Opinion's are not good enough, market and competitive data are needed to be prepared. Have you talked to customers? Prepare thoughtful questions and research.

Of course there are many more lessons I've learned, but that's enough for today....

The "Success Singularity"

Sometimes we are so focused on what has to get done next and what am I doing to get this project or product done, that we lose our "finish line" focus. As a product manager who also done some heavy lifting as a project manager, I have had to learn to step back and think about what the finish line looks like and how will the team know when we have crossed it.

I called today's musing the success singularity, meaning the point at which everyone can agree that the project or task has been completed. It must be indivisible. This about a track race, how do you know it's done. Simple, when the finish line tape is broken. It is the perfect definition of a "Success Singularity". It defines completion of the race and it is indivisible. By providing your teams with "Success Singularity" criteria you provide clarity and direction while minimizing potential confusion over the completion of a task or project.

My First Post

Why am I creating this blog? Well that's a great question. As I have grown in my career, I wanted to have a broader dialogue with other professionals about some of my product management musings. I wanted to share some of my lessons learned and hopefully learn from you about your lessons.