During ProductCamp Toronto in October I was interviewed by Donna Popacosta on Business-Driven Product Management. She turned this into a podcast which is now available on the ProductCamp Toronto website. Thanks to Donna for putting all this together.
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.
Earlier this week Scott Wright of Streetwise Security Zone and I got together and created a podcast exploring security issues that product managers wrestle with when they transition to a SaaS model to deliver their product. Scott in this podcast offers some great tips and advice on the following topics:
- Moving from isolated software products to offering them as a service
- Basic considerations for securing services, assurance for customers
- Separating data between clients who could be competing with each other
- User login security considerations
- Who administers users, and who administers the system?
- The big picture – communicating new kinds of risks to senior management
I highly recommend product managers visit Scott’s website and blog to expand their knowledge in security. Thanks Scott!
Marketing and Operations together to leverage social networks to conduct business – that’s what social business is. This includes Product Management, Product Marketing, Product Development, Sales, Service and Customer Support. All of these groups within a company need to leverage social networks in an organized fashion to conduct business – i.e. generate revenue, improve customer satisfaction, etc.
As with any earth-changing technology, social networks are changing the way business needs to be conducted – companies need to get involved in the conversation as an integral part of they way they do business – Product Managers especially. Testing new ideas, improving existing capabilities, watching your competitors, etc. are all activities that the Product Manager needs to do on social networks – Twittter, Facebook, LinkedIn, etc. The first step is to identify your community – in other words the people and companies in your target market. Find out where these people have their conversations? All / some networks? This includes customers, prospects, competitors, influencers, users, etc. Product Managers must be part of the conversation to help achieve your company’s business objectives.
Are you ready? You had better be.
Too many companies view #ProdMgmt as a set of product managers who’s primary role is to manage the product requirements / backlog. They believe that as soon as they have hired one or more people to fill the role, product management is covered. That’s it; done … on to the next issue.
They can’t be further from the truth. Product management is about managing the product portfolio from initial concept through to end-of-life (EOL); maximizing the revenue their product(s) generate. This is the life-line of product companies … the entire company needs to realize that messing this up could be disastrous. Hence, product management is a philosophy that everyone needs to understand and determine what their role is in it.
This philosophy is about understanding that every decision anyone in the company makes has implications on the management of the product. Decisions by executives about where to invest or which markets to target are the obvious ones. But decisions by the finance group regarding contracts and/or licenses impact pricing and packaging or agreements with 3rd party suppliers impact the content or profitability model of the product are examples of those that are not so obvious. I challenge everyone to think of every department in their company and write down the decisions and actions by each department that potentially could impact the product(s) … you will soon see that there are many that impact the management of the product(s).
So as an executive, impart this philosophy on all of your employees … mandate that decisions and actions by everyone are fed into the product management process ensuring that fact-based product decisions are being made. As a product manager be proactive and set up your internal network so that you meet face-to-face monthly or quarterly to review the latest news to find out what will potentially have an impact on your product(s) … don’t be blind-sided.
Is your Organization Chart getting in the way of creating great products that delight your customers? Is it getting in the way of capturing more marketshare? Let’s face it, the basic structure of org charts has not changed. There’s the President along with Vice Presidents heading up the Finance, Marketing, R&D and Sales departments. But why are many companies so dysfunctional when it comes to defining, building and delivering products? Maybe it’s the structure of the organization. We’ve seen it / lived it over and over – marketing and R&D sometimes just do not play nicely together. Fiefdoms, egos, mistrust – whatever the reason, it can be a real toxic atmosphere. And when times are tough (as they are now) the departments hunker down protecting their turf. And Product Managers who straddle both sides bear the brunt of all this as they try to get products and releases out the door. It’s no wonder that defining, building and delivering products and releases can be sometimes so hard. But it doesn’t have to be.
If you are in a product-driven company – i.e. the business model for generating revenue is by defining, building and selling products – or transitioning into a product-driven company, then this blog post is for you. If you are a services-driven company and have no intentions of becoming a product-driven company, then maybe this post is not for you.
Generally speaking there are 3 major buckets of activities within a product-driven company. Finance and Corporate Services look after the internal workings of the company – making sure that everything is in place and operating properly (including adhering to GAAP so that the president stays out of jail, but I digress). Next is Sales and Services (if Services is a component of your product offering) who are responsible for extracting as much money out of new and existing customers as possible; whether it is direct, indirect, online, telesales, etc. And last (but not least) are the activities around finding markets, defining and building solutions to address market needs and supporting customers. The latter certainly sounds like Product Management. So why do we split this between Marketing and R&D? Why do we have separate fiefdoms to support this essential set of activities? Isn’t managing the product portfolio one of the most important activities in a product-driven company?
So we need to view the org chart from that perspective. I propose an org chart that views the activities of defining, building and delivering products as paramount.
As you can see I propose keeping the VP Finance and Corporate Services and VP Sales and Services roles intact. However the Marketing and R&D roles become the VP Product Management role. This group is chartered with finding markets and their problems, defining solutions to address those problems, building the product, launching the product, communicating its goodness and supporting the customer base. As you can see everything related to the product is in one group. You’ll notice that product development reports into Product Management and that the Technical Product Manager role is absent – it’s part of Product Development. Lastly we have the CTO role. This role is about future technology – embracing new technologies, searching for / inventing technology that will improve the product in the future.
The biggest benefit? The management of the product portfolio, which is the lifeline of a product-driven company, is now the priority … not marketing it, not building it.
Last week, Michael Ray Hopkin from the Product Management Pulse interviewed me on the topic of Business-Driven Product Management. The podcast is now posted on his site: http://www.productmanagementpulse.com/business-driven-product-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!
- 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.
- 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.
- 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.
Honestly – I’m probably the last person on earth to have figured out how to use Twitter. Ok, since I don’t know everybody there’s no guarantee that I’m the last. I’ve had a Twiter account for a year or so and it was not until a couple of days ago I figured out how to use it for business. I’ve tweeted on my half-marathon training, the weather, news and other personal topics, but never on business. So for those that have figured this out, no point continuing on. But for the others read on.
I wanted to get my early thoughts down while they are fresh – so here goes. I was stumped for months on figuring out who to follow, when I had no clue as to who was using Twitter. I managed to find some interesting people and began following them, but it was a stream of conversations that I couldn’t follow and frankly missed most of them as they scrolled by everyday. Over coffee with a local social media expert he put me on to Tweetdeck. So between Tweetdeck and the concept of #hashtags, my Twitter experience improved dramatically. Honestly!
With Tweetdeck you can view tweets that fall into categories that you define. For example, I’m interested in product management. So I set up a Tweetdeck search on all tweets that contain the #prodmgmt hashtag. Every time a tweet occurs with the #prodmgmt embedded in it, the tweet appears in my #prodmgmt search pane. Employees of companies, especially those involved with the core business have interests in the subject matter of their business as well as the role they play in the company. For example, if you are a product manager with a company that sells to the supply chain management space, you could set up a search pane for product management (#prodmgmt) and one for supply chain management (#scm). If you deliver your software as a service, set up a search pane with #saas as the search keyword, or #agile if you develop software using agile methods … you get the picture. On the subject matter end, if you’re in the DRM space use #drm as your keyword or if you’re in the FOIA space use #foia and so on. The #hashtags site allows you to search for registered tags – make sure that you pick ones that are active (i.e. there are posts at least hourly) for you to get any value.
Good luck! See you on Twitter!
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.