Tag Archives: agile

Product Marketing for an Agile World

At this month’s OCRI Zone5ive meeting I delivered a presentation entitled Product Marketing for an Ever-changing World. [The Ottawa Centre for Research and Innovation (OCRI) is Ottawa’s leading member-based economic development corporation for fostering the advancement of the region’s globally competitive knowledge-based institutions and industries.] The goal of this presentation was to educate the Zone5ive membership on how they can become more effective as the development team shifts to Agile development. This transition does not just impact the development team, it also impacts Product Marketing, Product Management and Marketing.

The net result is that product marketing (and product management) teams will have the ability to engage customers early and often throughout the project which will increase the chances of a successful product (or release) launch. In other words, by engaging customers during the project, they will feel like they helped shape the release (or capability or feature) and so will be in a better position to talk to the press and industry analysts. They will also help you with your messaging, i.e. they will provide with real value statements.

The Changing Role of the Product Manager

#ProdMgmt This is where I reveal my age! Ok, sort of. I remember the challenges of Product Managers 10 years or so ago. The major challenge back then for me was the activity of gathering information. Yes you would hear from your customers, but mostly when they wanted something or when something was not working – it was up to you to pick up the phone and call them. Another avenue for information was from analysts; an expensive option that returned slightly skewed information which was not really worth the money. Tradeshows were a great source of information – competition, customers, thought leaders, etc.; but incredibly expensive. Bottom-line – it was just plain tough and especially time-consuming to get solid, reliable information with which you made product decisions. The act of getting the information occupied a large percentage of the Product Manager’s time. Add to that, requirements writing and teaching / helping sales and well, there was no time left for anything strategic, let alone to try and stay ahead. Even after your release went GA and you distributed it to your customers, it took some time to get feedback … Beta programs occasionally worked, but not always.

Putting this into a Lean context, taking the time to gather information does not add direct value to the customer and therefore should be eliminated. In other words it is Muda.

Many Product Managers still operate this way today, but I’m seeing a growing trend of companies where Product Managers are spending their time responding to information rather than gathering it. In other words, instead of spending the time gathering information, they are doing something with it to add value to the product. Communication and the ease with which we can get information has the ability to significantly reduce the need to spend the time gathering information. Tools such as Twitter provide almost instant feedback from users. SF.com’s Ideas portal allows customers to post and vote on enhancement requests. The ability to intertwine your product and web-oriented feedback mechanisms makes it easy for customers to send you their feedback. From a Product Manager’s perspective the information freely flows in through these new mechanisms and they can now focus on what to add to the product to give the greatest value. The one new addition to the PM role is to monitor these new feedback mechanisms.

Two companies I know of push  a new release up to their site on a Friday and start monitoring the uptake and users behavior on Saturday. By Monday morning the Product Manager can assess and prioritize what needs to be done during the week. Another company uses their blog page for feedback. The link to the blog page is right there in the product to make it easy for customers to give feedback. Trends like these will continue far into the future.

Why is this happening? I see two reasons – and they are linked. First is that the rate and amount of change has increased. It is very difficult to maintain a steady course for more than 3 – 4 months. I remember not having to deal with change for a year. The other is the speed and breadth of communication. The web and the tools to mine data or the tools to send you data automatically has dramatically increased. They are linked because the more information available the more need to change what was decided.

It is very clear that our world has become and will continue to be agile – the roles of Product Manager, Product Owner, Business Analyst are in for a very exciting change. I look forward to this evolution!

Clearly Define your Product Manager Role!

As software product companies adopt agile principles, the role of the Product Manager is changing and therefore needs to be clearly defined and established. As more and more companies adopt agile principles, people aspiring to be Product Managers need to understand what’s in store for them over the next 5 – 10 years. Looking back over the past 5 – 10 years the greatest influencer on developing products is the increase in the amount of change. It used to be that Waterfall methodologies actually worked well. Why? The reason is that once all the up-front requirements gathering and design was completed the amount of change over the course of the implementation phase was negligible. Projects that lasted a year and delivered product that was still relevant, were quite common.

Times are different, we as consumers love choices; we love changing our minds; we love new and innovative products. Even users of B2B products see what’s happening with the technology in our private lives – for example, searching for information on the Web where variations in search terms are easily handled and returns the highest relevant item has become standard – so why can’t my B2B product have the same capabilities? This all ripples up to the developer of the product. Bottom-line is that the ability to embrace change is key to surviving … and with the amount of change increasing, this is becoming quite a challenge.

So the trend of switching from Waterfall methodologies to Agile methodologies as a way of embracing change continues. More and more software product companies (and hardware product companies with a software component to them) are adopting, to some degree, an Agile methodology (Scrum, XP, etc.) to help them gracefully embrace the change that will inevitably happen. How this happens is that the amount of up-front activity is reduced to the bare minimum (as compared to the Waterfall methodology) – essentially what’s required to support the first sprint/iteration is completed up-front. The consequence, however, is that the up-front work for each feature/enhancement takes place when needed during the project – more of a Kanban (pull) approach.

Agile methodologies (Scrum in particular) introduces the role of Product Owner. There is much debate as to whether this new role is in fact the Product Manager or what activities the Product Manager now performs. The Product Manager role is very broad – it encompasses strategic activities related to the current and future target markets, technical activities related to the actual product and communications/training/support activities related to launch and sales. The technical activities of the Product Manager role are very closely aligned with the activities of the Product Owner. In smaller companies these roles can be supported by a single person and as the company grows multiple people will be needed; split between Technical Product Manager and Product Owner where they work very closely together. Companies that already have an established Technical Product Manager role are in a good position to make this transition. The key is that this role must extend from the customer/users to the development team – user intimacy, feature prioritization, requirements definition and prioritization, customer validation, etc. are all part of the role. Technical Product Managers that are too deep into requirements and design need to “move” towards the users – i.e. they need to be more engaged with the users of the product.

Companies that do not have the role of Product Managers crisply defined, will struggle in their transition. Product Managers that do (or attempt to do) all of the activities encompassed by all segments of the role will not be able to properly embrace the cadence and needs of the Agile methodology. In other words, the ability to provide the up-front work at a just-in-time pace during the project will be severely hampered. Companies need to clearly define this “customer/user to development” role and staff it properly. Responding to change throughout the entire project is vital … customer feedback comes quickly, business objectives/situations change – all of which needs to be handled very quickly and in time so that development is always busy and working on the most important items.

So the bottom-line is that product companies need to staff a role – Technical Product Manager – that spans the length between the users and the development team. Whether this role is the same as the Product Owner, depends on the size of the company. Companies also need to staff a role – Marketing Product Manager – that looks for and understands the markets that are suitable for the company to embrace. For start-up companies that only have the resources to staff one position – staff the Technical Product Manager role (as defined above) first – understanding your users and building your product that delights them will pay huge dividends in the long run.

Transitioning from Waterfall to Agile

Is your transition plan in place? Are you thinking ahead to that inevitable moment? Summer holidays are starting to happen. I can, with almost 100% certainty, state that a product manager in some company will return from holidays to hear that familiar refrain – ” we have switched to agile … oh by the way where’s the backlog”.

So before that happens when you, Mr. Product Manager, return from your fabulously relaxing holiday and you get even further behind, here are some important ideas to ponder and some key items to have at the ready before you head out on your holidays.

  1. Make sure that you have a system and process in place to easily and quickly manage your list of enhancements (the requests from customers and what you need to do to your product to help increase sales in current and potential markets). In the old methodology you were able to assemble and debate the features on the list early in the project and that’s what development agreed to build over an agreed upon timeframe. Now however the cadence of your development team (e.g. the sprint or iteration length) is short and so you need to be able to re-prioritize your list very quickly; you need to add and prioritize new items easily and quickly; and you need to be able to handle changes in business priorities very quickly. Before every sprint your list needs to be up-to-date.
  2. Make sure you reset the expectations of your executive team. In the old methodology the executive either fully participated in creating the list of features or they were peripheral to the process but kept their finger on the status of the meetings. In any event, the result was a list of features that development agreed to build within the agreed timeframe. Now with an agile methodology your executive has visibility at the sprint level. In other words, the horizon of agreement is far shorter with this new methodology; they do not have the full list of features that will be in the release – it is revealed sprint by sprint. The upside for your executive team is that the ability to embrace and react to change is far easier than with the old methodology.
  3. Make sure that you have a system in place that gives as much visibility of the project status as possible to as many stakeholders as possible. Your system should be easy to update from one sprint to the next. Executives like the high level picture – what enhancements are done, which ones are underway and which ones are ‘on deck’. Make this information available to them in real-time and make sure that the status is updated as soon as the state changes.
  4. Make sure that you have the ability and a process to assess when you have developed enough value for the release. Early in the project define the objectives of the release. Then later in the project, evaluate what has been completed against the objectives at the end of every sprint. At some point you will need to decide that you have enough value to go to market with. Everyone needs to be in agreement as to how this will be evaluated.
  5. Make sure that you gain an understanding with development on the product manager vs. product owner roles. Understand the product owner role and the differences / similarities with your role as a product manager. If you take on the product owner role then make sure that development understands that you still need to leave the office and visit customers – maybe at the most inopportune time.

If you think through these points and come up with an action plan, your transition will be relatively smooth.

Are you now a Product Manager or a Product Owner?

Agile has certainly changed the way Product Managers are perceived. In fact it raises the question within organizations that are moving to an Agile environment about what Product Management does. It raises the role of the product manager and the need for product management to the executive ranks – if it was not there already. But even though product managers have that title, are they really performing this role in an Agile environment. There are many blogs and tweets about this topic; my goal is to determine how many product managers in companies that use an Agile methodology actually perform the tasks of a product manager or do they in fact perform the tasks of a product owner.

Before we get too far ahead of ourselves, let’s look at some of the key activities for a product manager and for a product owner.

Product Managers own the product roadmap and the release strategy – they worry about the big picture. They work with all the stakeholders to maintain the roadmap and thus each of the releases and the vision for those releases are part of their responsibility. To do this effectively they need to get out and visit customers and be “plugged-in” to their target markets and the problems these markets have. They define the priority of the enhancements needed for the product based on meeting business objectives. To them the success of the product is paramount. They look for new markets for the product or ways to expand the reach of the product in existing markets.

Product Owners are responsible for delivering to the release plan – they are heavily involved in the day-to-day operations. Their focus is iteration by iteration. They write/elaborate user stories and prioritize them for each iteration so that iteration deadlines can be met. They virtually “live” with the development team(s), attending all stand-up meetings through each of the iterations. They understand the user stories extremely well and deep.

So now onto the poll.

[poll id=”3″]

If you picked that you are a Product Manager and primarily perform product owner activities, please answer the following.

[poll id=”4″]

Both roles are key to delivering products. Smaller companies in most cases cannot staff both positions. But it’s imperative that all companies understand the difference in the roles and make sure that both are adequately covered and that clear lines of delineation are drawn between the roles.

Thanks for participating.

Iterative Requirements Management

Your release plan is done (or as done as it’s going to be at this stage). Your best estimates indicate that the development team can probably implement the top 10 to 15 items to meet an acceptable window of opportunity. The team has committed to implementing the top 3 or 4 items in the backlog in the first iteration. So now what? Well, open Word with your trusty, well-used, highly refined requirements specification template and begin writing requirements. Right? WRONG! This template probably started with great lean-ness to it; but over time more sections were added to make it “complete” … until the next new section is added. I see this so often that I wonder why we do this. We essentially are asking our product management team to write full requirements specifications within a short period of time. If you have a small PM team, then it’s virtually an impossible request. The result is that requirements are late, incomplete, not at the right level of depth, maybe even all of the above. Which means that the development team will usually “wing” it, and the PM task turns into a retro-specing exercise. Whether using an Agile methodology or a Unified Process methodology, our development teams develop iteratively (at least they should). They focus in on the next iteration and “grow” the release as they move from iteration to iteration. They tackle the high risk items early in the project. Etc. Etc. So why are requirements managed differently? Maybe because the template was approved some time ago in response to some botched feature and no one took a step back and asked how this can be better performed.

The goal of documenting requirements is to record the needs of the users in terms that development can build from. In other words the spec translates what the user needs to solve one or more of their problems into a format that development can use to design and build from. The underlying goal is that the development team needs to understand what it is that needs to be built so that they can come up with a design and an estimate for effort and risk. Collaboration between product management (representatives of the customers) and product development is essential … throwing a fully-baked requirements spec over the wall does not constitute collaboration. Presenting the requirements in layers is a better approach to achieving the goal.

So let’s break this process down into three essential layers where we present information in ever increasing depth and amount until development understands what they need to do … and no further!

  1. Key Requirements. The first layer is an identification of the essential requirements – those that drive / shape the feature or capability. These are the requirements that are non-negotiable, i.e. you can not go to market without these being met. The first step is to make sure that these key requirements are captured. I recommend no more than 5 requirements, expressed as user stories or high-level use cases or declarative statements – the point is that you capture them so that the development team understands them. Present them to the team (or a subset of the team) as soon as you have them, from which they should begin thinking of the design and effort and risk.
  2. One-page Requirements Document. If step 1 is not sufficient enough, i.e. the development team does not have enough information to come up with estimates for effort and risk, then the next layer is to create a single page requirements specification. Add detail such as usage scenario, actor/persona, problem solved and more depth to the key requirements and possibly even more requirements. Remember that the goal does not change – development needs to get to a level of understanding where they can come up with a design and effort and risk estimates.
  3. Requirements Specification. If the previous steps are not sufficient, then the full-blown requirements spec is the last layer. In these cases the feature / capability is possibly something brand new being added to the product. You should consider maybe dividing this into smaller chunks; in some cases that may not be possible.

By managing your requirements iteratively you can put the appropriate amount of effort into your requirements that’s needed to achieve the goal (i.e. develpoment understands what’s needed from them). Do not waste your time writing requirements that do not add value to achieving this goal. In other words, once you have reached your goal, stop and move on to the next item.

Product management by committee … how sustainable is it?

I recently talked to another early stage software company that is managing their product portfolio by committee. Oddly enough they too are using an agile development approach – I believe that the committee approach fits well into the notion of daily meetings, product backlogs on the whiteboard, etc. Regardless of the development methodology I wonder how sustainable this is. At what point does this method of managing products breaks down?

Early stage companies typically have a dozen employees or so. What I’ve seen so far is that the committee consists of a combination of the CEO, head of development, Chief Architect, and head of marketing. One or more members are usually the founders / visionaries. Now each have their own roles within the company and they devote a portion of their time (roughly 10%) on the product management activity. The committee primarily decides what goes into the product and when. All works well, but the challenge they face as the company grows is that the members of the committee become more consumed with their primary roles (as they should) and the product management activities fall by the wayside. The result is that a single person – usually the head of development or the chief architect – takes on the task of deciding what goes into the product. But as the development team grows, these product management decisions are made from an internal perspective and not from the outside in as they should be. I believe that as companies approach and move through the $1.5M to $3.0M annual revenue milestone and/or the 20-25 employee threshold, they will see the breakdown of the product management by committee methodology. Most notably, committee members find it a challenge to attend meetings and to focus on the details of what needs to go into the product.

Here are some of suggestions to help get through this phase … (1) hire a product manager with product management experience, (2) invest in building an infrastructure (processes, artifacts, etc.) that meets the needs of your development methodology, (3) document your core competency, market problems you solve and why you add value, and (4) setup regular status meetings with the stakeholders. The key is to setup your product management methodology to support the next stage of your companies growth.

Is your Product Management process Agile?

I’ve read many articles on whether product managers need to become agile as the development team embraces an Agile development methodology. Saeed wrote a great article for the March ’09 pragmaticmarketing.com newsletter proving that, in accordance with the Agile Manifesto, product managers have been living the elements of the Manifesto for some time (but may not have known it). Having been with companies that decided to ditch non-Agile methods and embrace Agile development the biggest challenge for my PM team was not for the product managers to become agile (or more agile) but instead the timing of when they perform their activities. Long gone where the days of a 6-8 week planning cycle where product managers brought everything to the table and the horse-trading began. It now meant that the team had to on a regular, timely basis (synchronized with the iteration cycle) prioritize new requests for the backlog, analyze the current backlog, and describe the usage scenario and key requirements as quickly as possible … as well as meeting with customers, performing market research, liaising with the development team on the work items of the current iteration, etc.

It also meant that the team became engaged with the project throughout its lifecycle on a more consistent basis instead of cyclical as was the case with the non-Agile method – i.e. the PM resource loading for the project remained relatively constant. It also meant that they needed to iterate through the requirements gathering / analysis / documentation process. First was to understand the top 5 requirements that meet the request and convey that to the development team. Next was to drill a little deeper in areas where dev neede more understanding. And lastly was to stop, when dev understood what was needed (I recommend reading Lean Software Development by Poppendieck – it provides a great discipline for this type of an environment).

In order to become business-driven in an agile world, product management processes need to be tuned so that product managers can perform all the activities that are needed so that business objectives are met.

Business-driven Product Management

Hi-tech companies grow … they get a healthy, active customer base that loves to contribute. The requests for improvements flow in and the attitude for the first few years is “whatever the customers want” and “whatever to make the sale”. At some point in this growth, the challenge becomes satisfying existing customers, expanding into new markets or deeper into existing markets and innovating the product.

So, what’s the problem? In order to make all fronts happy, you need to balance all three – or least understand that you consciously need to examine all three to determine their relative importance to your company. With a finite set of development, qa, and documentation resources, that in all but the rarest cases, can not do everything, this becomes a real challenge.

Here are the potential results of not addressing this challenge.

  • Customer dis-satisfaction – unhappy customers question whether they should renew their maintenance and support contract – jeopardizing a revenue stream that accounts for 18% to 28% of the initial license sale or, in the case of a SaaS model, the actual contract may be in jeopardy.
  • Inability to expand markets – expanding into new markets or expanding within current markets means  more potential new name accounts – failing here means not getting the revenue.
  • Unable to innovate at the technology level – products that have been around for a few years, need updating to leverage an updated infra-structure or need improvements to make that next big innovative leap in the market – lagging behind invites new competitors to jump in.

Each of these generate innovative ideas (features) or they expose gaps in the product that need to be filled. Business-driven product management is about deciding what to include in the product to best meet balancing the investment in Customer Satisfaction, Market Expansion and Technology Innovation.

A weighted set of business objectives reflects the goals of the business for the near, medium and/or far terms. In other words, it determines the priority of your investment. Are you going to invest more in making customers happy (or happier)? Or is investing in expanding into another market more important. Assessing the feature requests against these objectives will determine the relative importance of these requests and thus your product releases will match your corporate goals. There’s no point in investing in features that do not move you closer to your objectives!

Product Management for Start-ups

Hi-tech start-ups are primarily driven by technology enthusiasts – someone or some group has an idea and away they go. Their focus is on the technology – building on their collective vision. Their tendency is to add to their vision as they encounter potential customers – building the product and expanding their target market as they go. Unlike companies beyond this stage, start-ups do not have the luxury of leaning on a customer base for information to drive the direction of the product. Unfortunately by using this ad-hoc way of managing their product, start-ups ingrain these habits into their everyday processes. As they grow up and suddenly have to juggle customers as well as expanding into markets, these habits become a serious limitation to being able to operate at their best.

But despite the lack of a customer base, start-ups need product management. Product management is about determining what’s important to build; who you are building the product for and when to roll out the capabilities. Start-ups have limited resources so in order to gain the biggest bang for their development dollars, they need to understand what to build first, then second, third, and so on.

Product management is a collection of many activities – from strategic to tactical and from business to technical – the breadth of which can be overwhelming. But there are 3 key activities that are critical to setting the right product management tone in the start-up company.

  • Differentiation – identify and articulate how you are different than any alternative your target market has. Maybe you have a direct competitor, maybe you don’t – the point is that your potential customers will compare you to alternatives (including the status quo). Your differentiation needs to be based on your core competency, but must be articulated from the perspective of your target market. How uniquely do you solve the markets problems better than any alternative?
  • Market Problems – identify and articulate the market problems that your product addresses. These need to be from the perspective of your potential customers – not from the features in your product. When you are in front of a prospect, they will resonate with the problems your product can solve – not with the features you have. Once you’ve identified and articulated the problems, prioritize them. This will focus your scarce development resources on building the most important features and capabilities first.
  • Value Chain Mapping – your product will touch a number of different people or entities as it is deployed and used. You need to identify the value every single person or groups of people or entity will receive from your product. In some cases it may simply be monetary – in other cases it may be usage oriented. If your product does not provide visible, measurable value to everyone in the chain, then someone (group or entity) will not be a supporter of your product – potentially blocking the sale.

And lastly – validate, validate, validate. As a start-up this is tough. Maybe you have a few people in your industry that you can call on – so long as they are respresentative of your target market. Maybe you have some past experience. Maybe you are lucky enough to have a small sample of customers – word of warning, a small sample can skew your findings, so be aware. The point is to get out to as many people that are in or a have a vested interested in your target market to get feedback. To paint the best picture for your audience have a prototype to show the key concepts and a presentation to describe the entire offering.