Wednesday, January 31, 2007
Kathy Sierra just has a habit of getting it right all the time, why can't I do that?! Make sure to subscribe.
Friday, January 26, 2007
Back to my networking event - someone asked the question: "well if you are listening all the time to what these customers are asking for and prioritizing/implementing purely based on that feedback, then who is responsible for innovation in your product?!". Interesting question.
The question may seem simple. The answer is pretty simple too actually.
Answer: your Customer certainly aint responsible for your product innovation! They are responsible for telling you their pains. They are responsible for telling you "wouldn't it be great if it did x when I hit y". They are responsible for running their business, and innovation within THEIR business model. They are NOT responsible for YOUR innovation, YOU as a PM are.
For example - I'll hazard a guess here and say that Customers themselves were not responsible for cool inventions such as the iPod. All that users probably said to Apple (this is all pure conjecture for the attorneys out there - disclaimer/tm yada yada) is: "I want to have a device that makes it easy for me to listen to my tunes." Apple did the rest in terms of delivering a truly innovative product - and the rest is history - until someone innovates better than Apple of course :-). Don't expect innovation from your Customers, it is not their business to give that to you either. They have enough on their hands running their business and their lives, and is not fair to ask them to do your job and theirs. This holds true even if the "business" challenge for the night is the 16 year old who has to update her myspace profile before the major cheerleading event on the next day! :-)
Net it is your job as a PM to drive innovation. It is your job as a PM to optimize, streamline, and improve your Customer's existence through product innovation. Expect this from Customers and you will be sorely disappointed.
Taking a step back, if we look at the categories of product innovation, they come in two basic forms:
- Those where PMs translate customer requests and pains into greater things. As I mentioned before, customers will eagerly tell you their pains and "wouldn't it be great ifs". These are feature requests - sometimes they are camouflaged in bug reports. These are not REQUIREMENTS though. Requirements are the inputs you deliver to your Development team. And importantly, they should be groups of what appear to be related (or sometimes unrelated) feature requests synthesised into a single requirement. For example, Customer A may ask for this feature: "wouldn't it be great if I hit this button and it did X." Customer B may ask for this feature: "wouldn't it be great if I hit this link, it did Y and then did X". Different feature requests, but similar potential need - there could be an innovative requirement hidden in here that differs from what the two customers requested, but solves both their problems. Very important to understand this - feature requests are not requirements - requirements are derived from feature requests, and may not represent exactly what the Customer requested, but still addresses the problem they had, and maybe goes beyond that...
- Raw great ideas. These are those ideas that come up with little Customer input, but again are driven through some vision derived off an indirect market pain. These are often the greatest innovative features. Google's PageRank is an example. There weren't any Customers asking for this were there? Yet the founders of Google thought of a cool idea, thew something out there, and innovated and iterated rapidly. And the rest is history. You should not be afraid to pursue these. My only word of advice is keep it simple, keep it pure - get your concept out there quickly, start iterating, and let the market tell you if it is a money or poopoo idea sooner rather than later.
I have one final point on the topic - PM should not solely be responsible for product innovation within a company. Innovation can come in many forms - maybe you have a scenario where one of your engineers comes up with a way to dramatically enhance the architecture of your product in a way that opens your product up to new business (APIs etc) - that is an example of innovation, although everyone does it today (you get my point though). Engineers are often the most creative people in the company, and we don't leverage that creativity in many many cases (more on this in a separate post). The way to effectively harness a strong engineer's creativity, and direct that towards the product, is to do things like getting engineers on Customer visits with you. That way they see the PAIN themselves, they feel what the Customer is feeling - and innovation ideas they have will be so much more grounded. Net - PM should not be the bottleneck for product innovation - empower the rest of your organization through Customer familiarity and real-world experience to participate in the innovation game too. Do this, and you and your TEAM will do great things.
Comments, thoughts welcome.
Monday, January 22, 2007
Are you looking to make the jump to agile release models such as Scrum and XP? Worried about whether your current tools will effectively support the new methodologies? Well, the tools you use are probably the least of your worries. If you want to ensure that your switch to Scrum (lets use Scrum for now as the example), your #1 priority should be ensuring that your Development/QA team is culturally equipped to handle the change...
Making the switch from a traditional longer/'non agile' release paradigm to something more agile like Scrum may seem simple, but it is not as simple as it looks. Here are some tips that should help your Development and QA teams navigate the transition with the least amount of hiccups as possible:
- Breaking up is hard to do. One of the biggest challenges you will face is in migrating to an agile model, is that your Dev/QA team will probably be used to longer release cycles - maybe 3 months release cycles on average, maybe longer - 6-12 months. Regardless of the duration, Scrum typically has releases in the range of 30-60 days, and this in itself presents all sorts of new challenges. The biggest challenge of which, is your team will not be used to pushing a release out every 30 days (lets use 30 days as an example, it could be 60 days etc). The Dev/QA team will now have to learn for example how to break a 3 month architecture project across 3 releases of 30 days each. And if a feature is not ready to ship in the first 30 days, they have to figure out how to manipulate their code to 'hide' features that are not ready for prime-time yet. Not to forget, you also need to make sure that your release build processes are in shape to handle the accelerated release rate. None of these are insurmountable challenges though - they are just some of those simple things that if you don't pay attention to early on, can come back and bite you in the rear. And no one likes being bitten in the rear.
- Keep it simple. Keep it flexible. Scrum has a ton of guidelines and best practices. You don't have to follow them ALL to the T though. For example, many books state you should do your daily stand-up in the morning when everyone is fresh (sorry non-morning people). However, what if you are on the east coast and some of your Dev team is on the west coast? I don't know many developers who are ready to rise and shine at 6AM :-) So keep it flexible, if the morning doesn't work - do the stand-up at the end of the day (have to give credit to our Director of Dev who came up with this one). In the end all you as a product manager need to focus on is the end goal - shipping kick-ass features at regular, controlled intervals with maximum opportunity for customer feedback. Whatever approach you take to reach that goal is up to you.
- Ease into it. Lets say your company has 14 product-lines. In the interest of maintaining sanity and risk reduction, do NOT try to move to a new release model for all product-lines at once. This is one of the biggest mistakes that people make. Culturally, the organization will probably not be able to handle it. To minimize risk, do one product-line first. You decide which line is best. Maybe choose it based on the enthusiasm of the developers in the team (enthusiastic people have a way of making challenging things happen). Maybe choose the product-line based on the fact that it is on a relatively independent code-base. And if the project then is not as successful as intended (to my next point), the impact on the other product-lines will be minimal.
- Success may take a little time. Switching to a new release model is tough on any company. Be prepared for it to potentially take a little while to succeed. Your first Scrum release may not be a success, you may even have to scrap the first release totally (don't let the team off the hook too easily though, keep the heat on :-). So be prepared for this, set expectations appropriately. If possible, choose a simple project for your first release, it will help reduce risk. Choosing a huge, mission critical, high visibility, time sensitive project is probably not the best way to go for the first try. Again, keep it as simple as possible on the first go round.
- Product Owners should not be Scrum Masters. This is something specific to Scrum. Product Owners are the sponsors of the features going into the product - they provide the direction and guidance on what features should go in the release, and how they should be delivered to the Customer. It makes sense that it is the product manager in this role. Scrum Masters on the other hand, are the release project managers. They ensure everyone is doing their thing, obstacles are moved out of the way, risks are identified and eliminated. This should NOT be the product manager. If the product manager is playing Scrum Master and Product Owner, they will never come up for air, and will likely lose track of important PM stuff like the industry and the competition - which is no good. What works best is a dedicated Scrum Master role in your organization (who has strong project management skills of course). But if budgets are tight, what you could do is have one Scrum Master first who is shared across a few projects (it is OK if this is a part time gig for the person initially), and then grow more Scrum Masters as the budget/success permits - all up to you.
That's it for now. In summary, it is all about keeping things simple, setting expectations appropriately, and not trying to 'boil the ocean' with the 1.0. I'll probably do a post soon on the benefits of agile, iterative release approaches vs some of the traditional release models.
Friday, January 19, 2007
This will be a short post/rant to begin my series.
I’ll start of with the conclusion and then loop back and explain my reasoning: Every company that ships products and has VP Marketing, should have a VP Product Management too. Why?
Product Management (PM) as a function has evolved over the years. Certainly it is becoming better understood within organizations as time goes on. But…as I look at many organizations out there, it is still one of the most the most misunderstood functions in the company, and often poorly leveraged as a result.
In some organizations, PM is still a part of the engineering group (mmm…). This may work in some rare instances, but in most cases – it is a failing proposition. Engineering’s charter, although critical of course :-), is too narrowly focused to properly encompass all of PM’s duties, and ensure that the group is serving the company as best it can.
We are not all off the hook yet.
Here is what I typically see as the status quo today though – it is the situation where PM is embedded within the marketing group - reporting up to the VP of Marketing. In smaller companies, with limited budgets, products, and funding - this works – as you get larger though (with more complex marketing and product deliverables), I start to see problems. PM being in Marketing simply does not put the group in the best position for success. There are a couple of reasons for this:
- In many cases, I see the VP Marketing and their organization are more focused on marcomm, PR, lead generation, product marketing (different to product management) etc – than on pure product management. Bring this VP Marketing into an executive meeting and product questions arise, it is often not he/she answering these questions, but the VP of Development (wrong!) Again, this is not the case across the board for every company, but I have seen it more frequently than less. And you know what the funny thing is - I don’t really blame the VP Marketing for stumbling sometimes! In my view, taking on all the classical marketing functions AND product management is becoming way too much for many marketing organizations today.
- PM is a 'hub' role – it sits at the center of the ‘product wheel’ and makes sure all the spokes are running as efficiently as possible. PM touches many parts of an organization. Marketing is just one of them. PM is also deeply involved with Development, QA, Sales, Legal, Finance, Tech Operations (if you are a SaaS company), Support, Services – and the list goes on and on. Marketing interaction is just one of the small pieces, (although critical, lets not reduce the value) in the PM’s world. Having the PM in the marketing organization does not put the group in the best position to efficiently drive cross organizational communication in my view. Separate it out and give it the identity it deserves.
- Executive visibility. To my first bullet above, if you are shipping products – then products are the life-blood of your company. Take away your products, and the company does not exist. Why put PM in the marketing organization if products are so critical? As a CEO, wouldn't I want someone reporting directly to me with a deep deep focus on product strategy and the success of my products?
Which leads me to my summary above – we need more VPs of Product Management. Since PM is such a critical ‘hub’ function in an company, it needs the benefit of a being its own organization, with strong executive visibility (through the VP Product Management who reports to the CEO). This structure better positions PM to more effectively collaborate across multiple groups - without the danger of competing marketing or engineering agendas hurting it. And most importantly, reporting directly into the CEO also gives the CEO the strong visibility they need into product direction, and puts PM in a better position to ensure they have the exec visibility for continued success.
So CEOs, VPs of Marketing – think about this. Are you putting your organization in the best position for success? Is your marketing organization trying to take on too much? If so – look into splitting that PM organization out and establishing a VP of Product Management. And, if as a CEO you think it will give you too many direct reports – ask yourself – have you best structured your organization to succeed? Aren’t products after all what make my company and help feed my employees and their families? Let’s get more VP Product Management roles out there.
That’s it for now – thoughts and comments welcome.