Jun 2008
Product Strategy in an Agile World
06.28.08 Filed in: SVPG Blog
Recently I spoke with a team of very frustrated Scrum engineers. They were frustrated because they felt like all they were doing for the past year was chasing features and that the product manager really had no clue where they were heading or what they were really trying to accomplish. When I spoke to the product manager (product owner in Scrum lingo), he explained that he thought the whole idea of Agile methods like Scrum was to remain flexible and “agile” and that he didn’t think he was supposed to worry about or lock in a longer-term direction.
This is not the first time I’ve seen this confusion, and I fear that creating an effective product strategy may have become an unintended casualty of the move to Agile methods.
So I thought it would be useful to discuss what a product strategy is, why it is critically important to do, and how it is actually completely compatible with an Agile philosophy.
First, a product strategy is meant to describe the vision of what you are trying to accomplish. Usually the timeframe is between two and five years out. It is a visionary work and meant to be persuasive. It is definitely not a spec in any sense.
Sometimes the product strategy is articulated in the form of a web page on a project Wiki, sometimes it’s a white paper, sometimes it’s a PowerPoint deck, and sometimes it’s in the form of a video of you evangelizing the vision. Partly the medium depends on how many people you need to communicate your product strategy to, and whether you can do so in person or whether it must be self-contained. In any case, it should be clear, compelling and inspiring. How will things be better when this product or service reaches its potential? It’s not about the specific features or functionality that may or may not be built, but rather the benefits of having this product. What problems will be solved with this product? Why will users love this product? How will the world be better once this vision is reality?
Second, the product strategy is the bridge between the business strategy and the product roadmap. The product strategy must support the business strategy, and the product roadmap is what describes your current plan of how you will get from where you are today, to the vision described in your product strategy.
Make sure you don’t confuse the business strategy with the product strategy. The business strategy might be something like “expand our e-commerce offering to allow buyers in Europe and Asia.” The product strategy might then describe the eventual e-commerce offering that has the necessary language support, currency conversions, payment methods, shipping and fulfillment methods, customs controls, etc. that you would need to support this business strategy.
Third, coming up with a good product strategy is one of the most important things a product manager (or very often, the director of product management) does. It’s not easy but without it you have little hope of actually ending up with something worthwhile. It’s like the old saying that if you don’t know where you’re going, any path will do.
We come up with a product strategy by first gaining a deep understanding of our target users, the market, and the underlying technologies. There will be brainstorming and lots of debate. You should actively involve your lead designers and lead engineers in this discussion, as well as key stakeholders. The product strategy is something that you will discuss and review actively with your management. Your executive team should care deeply about this product strategy.
Many product managers make the mistake of believing that the product strategy must come down from above, and in some cases it does, especially if you’re in a startup with a founder serving as the product visionary. But if not, you need to propose the product strategy and offer it up to your management for their review. This is a great opportunity for you to step up.
But defining and building features without a well thought out product strategy is very likely a waste of time and money.
Fourth, it is essential to understand that the product strategy does not lock you into any particular features or sequencing. Features and sequencing are represented in the product roadmap (the backlog in Scrum lingo). You can, and absolutely should, adjust the roadmap constantly based on what you learn from your users, the market, your analytics, and the ever-changing technologies we build upon.
Finally, I have found that creating a set of product principles that accompany the product strategy will help you and the product team to make the many decisions and trade-offs that arise when you actually define the features and the user experience. The product principles go along with and support the product strategy. You can read more about product principles at http://www.svpg.com/blog/files/product_manifesto.html.
Hopefully you can see that the notion of having a vision of what you are trying to accomplish is not in any sense inconsistent with the principles of Agile methods. I argue in fact that Agile methods, applied properly, will help you make your product strategy a reality significantly faster than conventional methods.
If you don’t have a product strategy for your product, I strongly suggest you take a breath, step back and ask yourself what you’re trying to accomplish? In three years or so, what do you want this product to be? How will you measure or recognize this state? Then share this vision with your management and with your product team – especially your engineers. They want to know where the product is heading too. It will help keep them motivated, they will have some faith that you as product manager are not just shooting from the hip, and also the strategy is important because it helps the engineers anticipate future capabilities and requirements which may impact the choices they make on technology and architecture.
Sign up for the free newsletter here.
This is not the first time I’ve seen this confusion, and I fear that creating an effective product strategy may have become an unintended casualty of the move to Agile methods.
So I thought it would be useful to discuss what a product strategy is, why it is critically important to do, and how it is actually completely compatible with an Agile philosophy.
First, a product strategy is meant to describe the vision of what you are trying to accomplish. Usually the timeframe is between two and five years out. It is a visionary work and meant to be persuasive. It is definitely not a spec in any sense.
Sometimes the product strategy is articulated in the form of a web page on a project Wiki, sometimes it’s a white paper, sometimes it’s a PowerPoint deck, and sometimes it’s in the form of a video of you evangelizing the vision. Partly the medium depends on how many people you need to communicate your product strategy to, and whether you can do so in person or whether it must be self-contained. In any case, it should be clear, compelling and inspiring. How will things be better when this product or service reaches its potential? It’s not about the specific features or functionality that may or may not be built, but rather the benefits of having this product. What problems will be solved with this product? Why will users love this product? How will the world be better once this vision is reality?
Second, the product strategy is the bridge between the business strategy and the product roadmap. The product strategy must support the business strategy, and the product roadmap is what describes your current plan of how you will get from where you are today, to the vision described in your product strategy.
Make sure you don’t confuse the business strategy with the product strategy. The business strategy might be something like “expand our e-commerce offering to allow buyers in Europe and Asia.” The product strategy might then describe the eventual e-commerce offering that has the necessary language support, currency conversions, payment methods, shipping and fulfillment methods, customs controls, etc. that you would need to support this business strategy.
Third, coming up with a good product strategy is one of the most important things a product manager (or very often, the director of product management) does. It’s not easy but without it you have little hope of actually ending up with something worthwhile. It’s like the old saying that if you don’t know where you’re going, any path will do.
We come up with a product strategy by first gaining a deep understanding of our target users, the market, and the underlying technologies. There will be brainstorming and lots of debate. You should actively involve your lead designers and lead engineers in this discussion, as well as key stakeholders. The product strategy is something that you will discuss and review actively with your management. Your executive team should care deeply about this product strategy.
Many product managers make the mistake of believing that the product strategy must come down from above, and in some cases it does, especially if you’re in a startup with a founder serving as the product visionary. But if not, you need to propose the product strategy and offer it up to your management for their review. This is a great opportunity for you to step up.
But defining and building features without a well thought out product strategy is very likely a waste of time and money.
Fourth, it is essential to understand that the product strategy does not lock you into any particular features or sequencing. Features and sequencing are represented in the product roadmap (the backlog in Scrum lingo). You can, and absolutely should, adjust the roadmap constantly based on what you learn from your users, the market, your analytics, and the ever-changing technologies we build upon.
Finally, I have found that creating a set of product principles that accompany the product strategy will help you and the product team to make the many decisions and trade-offs that arise when you actually define the features and the user experience. The product principles go along with and support the product strategy. You can read more about product principles at http://www.svpg.com/blog/files/product_manifesto.html.
Hopefully you can see that the notion of having a vision of what you are trying to accomplish is not in any sense inconsistent with the principles of Agile methods. I argue in fact that Agile methods, applied properly, will help you make your product strategy a reality significantly faster than conventional methods.
If you don’t have a product strategy for your product, I strongly suggest you take a breath, step back and ask yourself what you’re trying to accomplish? In three years or so, what do you want this product to be? How will you measure or recognize this state? Then share this vision with your management and with your product team – especially your engineers. They want to know where the product is heading too. It will help keep them motivated, they will have some faith that you as product manager are not just shooting from the hip, and also the strategy is important because it helps the engineers anticipate future capabilities and requirements which may impact the choices they make on technology and architecture.
Sign up for the free newsletter here.
What Makes a Great CTO?
06.18.08 Filed in: SVPG Blog
The job of the product manager is to define the products that the product development organization will build. Even with the greatest product ideas, if you can’t build and launch your service, it remains just an idea. So your relationship with the product development organization is all important.
I thought I would discuss in this article the leader of the product development organization. I wrote this piece together with my partner Chuck Geiger, as he has run several world-class product organizations. I have often said that if as product manager you have a good working relationship with your product development counterpart, then this is a great job. If you don’t, you’re in for some very tough days. So in the spirit of developing a better appreciation for what makes a great product development organization, we offer this summary.
First, let’s be clear which organization we’re referring to. This is the organization responsible for architecture, engineering, QA, site operations, site security, release management, and usually project management. This group is responsible for building and running the company’s products and services.
The titles vary, but often include VP Product Development, or CTO. For startups, the title is often simply VP Engineering, but as companies get larger, the focus is not solely on engineering and expands to product development and technology overall. In this article, we’ll refer to the head of this product development organization as the CTO – chief technology officer, but feel free to substitute the term your company uses.
There are five major responsibilities of a CTO. We present them here in priority order, and discuss how each is typically measured:
Organization
Build an excellent organization, with a strong management team committed to developing the skills of your employees. We typically measure effectiveness here by looking at development plans for all of the employees, the retention rate, and the evaluation of the managers and the overall product organization by the rest of the company.
Delivery
Make sure this organization can rapidly, reliably and repeatedly deliver quality product to market. There are several measures of delivery, including some measure of the quantity of work delivered, the consistency and frequency of release vehicles, and the quality/reliability of the delivered/launched software. Some organizations just look at reliability here, but productivity in the sense of quantity and quality is the real key.
Architecture
Make sure the company has an architecture necessary to deliver the functionality, scalability and performance it needs to in order to compete and thrive. The measures for architecture will vary based on your business, but in general we look to track and measure headroom/infrastructure work, and measure site outages due to architectural issues.
Discovery
Make sure that the architecture and senior engineering staff are participating actively, and contributing significantly, throughout product discovery. If your engineers and architects are only being used to write software then you are only getting a fraction of the value from them you should be. We suggest you track the participation of the product development/technology organization in product discovery (both duration and coverage), and the number of innovations that are credited to the engineering/architecture participant. It is also useful, although a little sensitive, to track changes to schedule post-discovery (churn), as you are always trying to reduce churn.
Evangelism
The CTO will serve as the company spokesperson for the product development/technology organization, demonstrating leadership in the community, with developers, partners and customers. This is often measured by establishing a university relations/recruitment program, and sponsoring or participating in at least two events per year in the developer community.
You may want to go to lunch with your engineering counterpart and discuss what they see as their biggest challenges and how you might be able to help from the product side. Anything you can do to help each other out will go a long way to creating a truly effective overall product organization, able to define and deliver winning products.
Email to a friend
Sign up for the free newsletter here.
I thought I would discuss in this article the leader of the product development organization. I wrote this piece together with my partner Chuck Geiger, as he has run several world-class product organizations. I have often said that if as product manager you have a good working relationship with your product development counterpart, then this is a great job. If you don’t, you’re in for some very tough days. So in the spirit of developing a better appreciation for what makes a great product development organization, we offer this summary.
First, let’s be clear which organization we’re referring to. This is the organization responsible for architecture, engineering, QA, site operations, site security, release management, and usually project management. This group is responsible for building and running the company’s products and services.
The titles vary, but often include VP Product Development, or CTO. For startups, the title is often simply VP Engineering, but as companies get larger, the focus is not solely on engineering and expands to product development and technology overall. In this article, we’ll refer to the head of this product development organization as the CTO – chief technology officer, but feel free to substitute the term your company uses.
There are five major responsibilities of a CTO. We present them here in priority order, and discuss how each is typically measured:
Organization
Build an excellent organization, with a strong management team committed to developing the skills of your employees. We typically measure effectiveness here by looking at development plans for all of the employees, the retention rate, and the evaluation of the managers and the overall product organization by the rest of the company.
Delivery
Make sure this organization can rapidly, reliably and repeatedly deliver quality product to market. There are several measures of delivery, including some measure of the quantity of work delivered, the consistency and frequency of release vehicles, and the quality/reliability of the delivered/launched software. Some organizations just look at reliability here, but productivity in the sense of quantity and quality is the real key.
Architecture
Make sure the company has an architecture necessary to deliver the functionality, scalability and performance it needs to in order to compete and thrive. The measures for architecture will vary based on your business, but in general we look to track and measure headroom/infrastructure work, and measure site outages due to architectural issues.
Discovery
Make sure that the architecture and senior engineering staff are participating actively, and contributing significantly, throughout product discovery. If your engineers and architects are only being used to write software then you are only getting a fraction of the value from them you should be. We suggest you track the participation of the product development/technology organization in product discovery (both duration and coverage), and the number of innovations that are credited to the engineering/architecture participant. It is also useful, although a little sensitive, to track changes to schedule post-discovery (churn), as you are always trying to reduce churn.
Evangelism
The CTO will serve as the company spokesperson for the product development/technology organization, demonstrating leadership in the community, with developers, partners and customers. This is often measured by establishing a university relations/recruitment program, and sponsoring or participating in at least two events per year in the developer community.
You may want to go to lunch with your engineering counterpart and discuss what they see as their biggest challenges and how you might be able to help from the product side. Anything you can do to help each other out will go a long way to creating a truly effective overall product organization, able to define and deliver winning products.
Email to a friend
Sign up for the free newsletter here.
Avoiding Design By Committee
06.02.08 Filed in: SVPG Blog
One of the big advantages that startups have is that there aren’t many people.
As companies get larger (even a little bit larger), one of the very common consequences is that decisions become group activities. Stakeholders pop up
from every direction. The notion of ownership gets diluted down to consensus builder. The objective moves from coming up with something great, to coming up with something that doesn’t get you fired.
And the result very often is that product innovation largely grinds to a halt.
There is no question that in larger companies there really are many stakeholders, and they really must be taken into account, as there is much more riding on your decisions than in a startup. But many companies struggle because they don’t know how to manage the stakeholders yet still make progress and innovate.
In this note I want to spell out the technique that I use to overcome this all too common problem.
But first, the key for every product discovery effort is to identify the three key people – the product manager, the user experience lead, and the product development lead. These are the three minds that must collaborate closely to solve problems in new and useful ways.
The product manager plays the lead role and brings to the table the knowledge of the functionality required, and is responsible for making sure the product has value.
The user experience lead represents the user’s behavior and mental model, and works to ensure the result is something that users can figure out.
And the product development lead brings to the table deep knowledge about what is possible, and is responsible for ensuring that the product that is defined is something that can actually be delivered.
Lots of other people are going to want to join your little party. Once in a while you may decide to include a guest or two, but it is absolutely critical that you keep this team small. You simply won’t innovate in a large group setting. This is not just a brainstorming session. You will be working through literally hundreds of small and large decisions, and your progress will slow to a crawl if you don’t have that small group of smart, empowered people.
It also doesn’t mean that your small group doesn’t have help. You have the resources of the company available to you as you need it. The most common resources are from the user experience extended team: especially prototyping, user research, visual designer, and user testing help. But you may need to go talk to legal about a sensitive issue, or the analytics people about how something is used today, or maybe you will talk to someone in site security about something you are nervous about.
The key is that your core team is empowered. Empowered to represent the stakeholders and to make decisions. But this doesn’t mean that you are given a blank check. You will have to review your decisions with the various stakeholders and make adjustments where necessary.
This is where I need to drill down to explain what I mean.
Each of the three members of your core product discovery team represent many different stakeholders:
The product manager as the overall product owner typically represents the business owner, company executives, sales, marketing, product marketing, legal, finance and customer support.
The user experience lead is very often an interaction designer but depending on the project may come from one of the other design areas, but in any case must represent interaction design, visual design, user research, usability engineering and often content/editorial.
The product development lead is very often from the architecture team or a lead engineer, but again, depending on the project may come from one of the other areas of product development, and must represent architecture, engineering, test automation, site operations, and site security.
For this model to work, the three members of the product discovery team really do need to be entrusted to give their best efforts while keeping in mind the needs of their stakeholders. But in truth it’s not that long of a leash. Your product discovery team still need to be able to show what you have come up with and are proposing before the product is actually built. This is one of the benefits of creating a prototype. You can show this prototype to any or all of their stakeholders so that they can see the reason for the decisions and what exactly is being proposed.
Often there is still some back and forth as stakeholders balance their issues against the potential of the product, but I can only tell you that the nature of the discussion is completely different when stakeholders can see the vision in a clickable prototype versus just talked about in the abstract or in some form of paper spec.
Moving to this model does require a little bit of a leap of faith. Management and stakeholders have to be willing to entrust you to represent their interests instead of being personally involved at the level they may be used to.
But the notion of a small group of talented and motivated people has always been key to coming up with great products. It is the basic ingredients of a startup, and you need to make sure you continue this as your company grows if you want to continue to create products that matter.
Email to a friend
Sign up for the free newsletter here.
As companies get larger (even a little bit larger), one of the very common consequences is that decisions become group activities. Stakeholders pop up
from every direction. The notion of ownership gets diluted down to consensus builder. The objective moves from coming up with something great, to coming up with something that doesn’t get you fired.
And the result very often is that product innovation largely grinds to a halt.
There is no question that in larger companies there really are many stakeholders, and they really must be taken into account, as there is much more riding on your decisions than in a startup. But many companies struggle because they don’t know how to manage the stakeholders yet still make progress and innovate.
In this note I want to spell out the technique that I use to overcome this all too common problem.
But first, the key for every product discovery effort is to identify the three key people – the product manager, the user experience lead, and the product development lead. These are the three minds that must collaborate closely to solve problems in new and useful ways.
The product manager plays the lead role and brings to the table the knowledge of the functionality required, and is responsible for making sure the product has value.
The user experience lead represents the user’s behavior and mental model, and works to ensure the result is something that users can figure out.
And the product development lead brings to the table deep knowledge about what is possible, and is responsible for ensuring that the product that is defined is something that can actually be delivered.
Lots of other people are going to want to join your little party. Once in a while you may decide to include a guest or two, but it is absolutely critical that you keep this team small. You simply won’t innovate in a large group setting. This is not just a brainstorming session. You will be working through literally hundreds of small and large decisions, and your progress will slow to a crawl if you don’t have that small group of smart, empowered people.
It also doesn’t mean that your small group doesn’t have help. You have the resources of the company available to you as you need it. The most common resources are from the user experience extended team: especially prototyping, user research, visual designer, and user testing help. But you may need to go talk to legal about a sensitive issue, or the analytics people about how something is used today, or maybe you will talk to someone in site security about something you are nervous about.
The key is that your core team is empowered. Empowered to represent the stakeholders and to make decisions. But this doesn’t mean that you are given a blank check. You will have to review your decisions with the various stakeholders and make adjustments where necessary.
This is where I need to drill down to explain what I mean.
Each of the three members of your core product discovery team represent many different stakeholders:
The product manager as the overall product owner typically represents the business owner, company executives, sales, marketing, product marketing, legal, finance and customer support.
The user experience lead is very often an interaction designer but depending on the project may come from one of the other design areas, but in any case must represent interaction design, visual design, user research, usability engineering and often content/editorial.
The product development lead is very often from the architecture team or a lead engineer, but again, depending on the project may come from one of the other areas of product development, and must represent architecture, engineering, test automation, site operations, and site security.
For this model to work, the three members of the product discovery team really do need to be entrusted to give their best efforts while keeping in mind the needs of their stakeholders. But in truth it’s not that long of a leash. Your product discovery team still need to be able to show what you have come up with and are proposing before the product is actually built. This is one of the benefits of creating a prototype. You can show this prototype to any or all of their stakeholders so that they can see the reason for the decisions and what exactly is being proposed.
Often there is still some back and forth as stakeholders balance their issues against the potential of the product, but I can only tell you that the nature of the discussion is completely different when stakeholders can see the vision in a clickable prototype versus just talked about in the abstract or in some form of paper spec.
Moving to this model does require a little bit of a leap of faith. Management and stakeholders have to be willing to entrust you to represent their interests instead of being personally involved at the level they may be used to.
But the notion of a small group of talented and motivated people has always been key to coming up with great products. It is the basic ingredients of a startup, and you need to make sure you continue this as your company grows if you want to continue to create products that matter.
Email to a friend
Sign up for the free newsletter here.
