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.
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.
#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!
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.
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.
I met with another company that is struggling to transition from a services based business model to a product based business model. Many hi-tech companies start out with a single contract to provide a solution to a particular client. They find more clients that need to address the same set of requirements … sort of – the solution is customized for each and every client. The net result is a handful of one-off solutions to different clients that address roughly the same need. Revenue grows; number of new-named accounts increases and now it is time to scale the business to the next level. Clearly creating these one-off solutions is not a scalable model – you are bounded by your development resource pool. The transition from a professional services driven model to a product-driven model needs to take place. A product-driven model revolves around the sale of a single (possibly configurable) product to customers who have the same needs, or problems that need to be solved. In other words, you develop a single product that you sell to many customers in your target market.
Sounds simple! But there are many challenges to making this transition … here are some of the key challenges:
- Moving away from the culture of ‘Yes’ – in a professional services model your goal is to secure that single contract and so saying yes to the wishes of that single customer to win that contract is paramount. In a product-driven model your goal is to sell your single product to as many customers within your market as possible. This means that you have to learn to say ‘No’. When a customer requests something, you have to determine if it has broad market applicability – if it does not have broad market applicability, then saying ‘No’ is your best answer. Why? You have finite resources and they need to be laser-focused on meeting your goal to secure as many customers from within your market as possible … divergences that do not move you towards your goal is a waste.
- Changing the feature debates – if the customer, in the professional services model, decides where you should deploy your development resources; who decides in the product-driven model? Clearly you make the decision; but at what level do you decide what to put in the product? Far too often the debate rages at a very high level, i.e. each of development, marketing, sales, customer support, etc. have their own top priority item that must go into the next release and so the discussion ends up being opinion-based. Business-driven product management brings the discussion level down to the objective level, i.e. the debate needs to be centered around how well each feature request meets a set of business objectives. The end result is that the business objectives control what goes into the product – not some subjective opinion.
- Assigning new ownership – in a product-driven model, product management owns the product. In other words, through their deep understanding of the market, their ability to objectively analyze requests, and with their full and complete view of the product, product management decides what goes into the product. The owner in the professional services model is the project manager or the account manager and their responsibility is solely focused on the client … not the market.
- Developing a process-driven approach – process has been given a bad rap. No one wants to be process heavy. On the other hand, a lack of process will not deliver the repeatability necessary to become a product-driven company. The process in this case is the clearly defined steps you go through to decide what features to put in the product, the interaction between product management and development. This process is the core of a product-driven company – if it does not operate efficiently and cost effectively, then delivering your products on-time with the right feature set to meet your goals will be a struggle.
Let me know if you can think of other challenges. Maybe you have an experience you would like to share.
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!