Category Archives: product requirement

Steven Haines @ ‘The Three Questions for Product Manager’

Steven HainesSteven Haines has a passion for great products! This passion is evident in the three books he’s written. His energy serves as a catalyst for senior leaders so that they can adopt needed changes that improve organizational effectiveness and ultimately, contribute to the creation of the best products that deliver extraordinary value to customers, and undisputed competitive advantage.

We thank Steven for taking out time and be part of ‘Three Questions’ series for product managers.

Product Mantra: How important is it for a product manager to have experience of project management?

Steven Haines: I have a good-news, bad-news response. The good news is that there’s recognition of a difference between the two. I can’t say how many times people confuse the two practices. The bad news is that, yes, product managers must know how to manage projects and the three main pillars: people, budgets, and schedules! To be precise, all business people should know how work gets done, by whom, and when. They must know who provides work product to others and who receives work product. Also, they must know how those hand-off’s impact the overall schedule of deliverables in order to produce a planned outcome. One of the most important projects that product managers are likely to find themselves in the heart of is a product launch. It’s an incredibly important process; it involves many people, and must result in an on-time launch. If people don’t do what’s required in the launch project plan, then the product will not achieve its objectives for sales, market share, or a positive customer experience.

Product Mantra: How often should a product manager conduct competitive analysis, what’s the frequency and any methods that you can share with us?

Steven Haines: Competitive profiling is a vital practice that should be carried out on an ongoing basis – not as a periodic exercise. For example, I get “alerts” every day on various companies to find out what they’re up to and I store them in my mind, or share information with my team members. I also motivate my cross-functional team members to be alert to goings-on in the market. If a sales person visits a customer and learns about a competitor proposal, that sales person should provide input to the product manager. Another method is for the development or engineering team to be able to reverse engineer competitor products if at all possible. This can provide valuable information on costs, composition, and the user experience. In many firms, a market intelligence department carries out research that can reveal useful insights. All these inputs should be stored on a shared repository so that, across the organization, people can be alerted to any competitive activities. These can be channeled into the strategic planning process, or in other dimensions of the product’s business.

Product Mantra: Tell us more about the philosophy of product manager as business manager?

Steven Haines: It’s not so much a philosophy, but the standard. A product is a business inside a business and a business must be managed. Every business starts with a vision, goals, and a strategy. That strategy is based on various inputs: market insights, business, and financial information. Strategic goals set the stage for what’s to be done – to create a new product, update an existing product, or even expand to another market. Once everyone in the organization is aligned, the product manager, like any good CEO or general manager ensures that everyone does their part to build, test, validate, and launch the product. Finally, performance metrics are monitored to steer the product’s business, keep things running, and to re-strategize as needed.

Thanks Steven.

Steven Haines on web:

  1. Steven Haines blog: http://sequentlearning.com/experts/author/sjhaines
  2. Twitter: @Steven_Haines
  3. Linkedin: https://www.linkedin.com/in/stevenjhaines

@mathurabhay

Advertisements

Matt Anderson @ ‘The Three Questions for Product Manager’

Matt Matt Andersonbroke into product management as a SME in library software, but has branched out into broader software categories. As a product manager, Matt has recent experience with B2B and B2G products, browser-based and mobile applications, and US and Canadian workforce regulations at several small companies in Salt Lake City. While working from Utah, Matt has worked extensively with offshore teams in India and Eastern Europe. Matt’s product management influences include Alicia Dixon, Rich Mironov, Roger Cauvin, Nils Davis, and the PM Dude. In his spare time, Matt tweets about product management best practices and broad technological trends.

We thank Matt for taking out time and be part of ‘Three Questions’ series for product managers.

Product Mantra: How do you see the role of product manager evolving in the world of Mobile Apps?

Matt Anderson: Mobile applications are often a new-ish product offering for companies that have established core products. In this sort of scenario, the mobile applications are often the most exciting area of development for the organization, while the core products are constantly focusing on the same things over the long-term: performance improvements, features, bug fixes, etc. Mobile products often have a shorter development cycle, a shorter testing process, and a smaller training and documentation effort. For someone who has been working as a product manager or engineer for non-mobile applications, it’s often a relief to move onto a mobile app project.

The learning curve, however, can be steep when you begin to work on mobile applications. Product managers working with mobile should look at and use applications regularly. They should look at mobile design patterns across the software industry. I’ve found it beneficial to carry multiple devices, with multiple brands, sizes, carriers, operating systems, etc. I’ve carried devices that were cheap or old when I thought the users may not use the latest and greatest. A product manager will have trouble balancing all of these conflicting concerns, so I’ve found it is good to rely on short release cycles, consistent beta releases, and constant feedback loops with users to release successful mobile products.

If I were to hire a product manager to work on a mobile application, I would look for a high-performer who was actively trying to understand (1) industry standards of UX design, (2) best practices for customer interviews, and (3) best practices for Agile. I’ve found that a solid background in product management and UX is a primary qualification for a mobile product management role, while experience in the mobile application space is a secondary qualification.

Product Mantra: How often do you conduct competitive analysis, and are there any methods that you can share with us?

Matt Anderson: I crawl the web daily for competitive insight in my industry by using Paper.li and Talkwalker Alerts. I think that establishing a constant flow of competitive data by using these tools is a great way to keep a constant dialog with your product management, marketing, and development teams. If I hear that my competitor’s Mobile App X is integrating with an API Y, I want to share that info with my team right away. That’s a daily competitive analysis, which may not be for everyone, but daily crawling is definitely my style. And if you use this strategy, don’t forget to pay attention also to your competitors’ major customers, because they drive your competitors’ strategy.

While I gather far more competitive insight from the web than from other means, the most valuable data is not always available on the web. I received one of the best pieces of competitive data in my career by attending an industry event and hearing that a government agency had worked with my competitors A, B, and C to draft legislation for my industry. Not all information is published to websites, Twitter, and LinkedIn. You need to be where your industry influences are, be where your customer base is, and be where your partners are. Visit your customers regularly, attend industry events, and you’ll work your way to the center of your industry.

I always find that the data that you gather from the competition over time needs to work its way into a higher-level analysis that compares your product offering with the competition. It could be a spreadsheet that shows feature quality for you and four competitors, or a spreadsheet with predictions of what each competitor’s feature offering will be in 2 years, or a pricing analysis in a spreadsheet that recommends dropping your price by 10% to improve your win-loss ratio. Take your competitive analysis and make it consumable by your executive team.

Product Mantra: What would be your suggestion for 3 Do’s and 3 Don’ts for Product Managers?

Matt Anderson:

Don’t just tell people what they want to hear; tell them what is going to happen. Don’t just say “yes” or “that’s a great idea” if you aren’t going to do it now. Tell them the real plan, and you’ll promote openness and trust.

Do work for your organization; not your department. As much as you can, be the best value to your organization. That means breaking down unnecessary interdepartmental silos and establishing a cooperative environment.

Don’t be the primary tester for your product. Sure, there are reasons why it can be a good thing. First and foremost, it is a great way for a product manager to understand the product and how it is used. However, a few of the consequences that arise from having product managers as the primary testers are impacts on the development process, conflicts of interest, and impacts on the performance of the product manager.

Do put your executive hat on. It’s not only the dev team and the user that matters…make sure that your product strategy is in line with your executive team’s expectations. Do it on a monthly basis, if possible.

Don’t gather the stakeholders and let them duke it out over what the priorities for the product are. You are being paid to make decisions about the product, not facilitate others to do so.

Do participate in the #prodmgmt community. I’ve learned so much from my colleagues in the product management community. I’ve met dozens of product management folks through my use of Twitter who have made my career and my life more fulfilling.

Thanks Matt.

Matt Anderson on web:

  1. Matt Anderson blog www.mattanderson.org/blog
  2. Twitter http://twitter.com/MattAndersonUT
  3. Linkedin http://www.linkedin.com/pub/matt-anderson/23/888/879

@mathurabhay

Product Managers are neither Astrologers nor Gamblers

Product Managers early into their career might get a bit frustrated when their product 300946273_d0b6f28186_mfeatures do not sometimes make an impact in the market with the users. Usually, they get questioned on why an investment was made in a feature which has made little or no impact. Does it mean good Product Managers have to be good astrologers? Not at all. If only Product Managers knew what the future is – so perfectly – they could have chosen a profession which is a lot more lucrative – professing the future for world leaders and business conglomerates – who struggle to make the right decisions. Product Managers work on features or products – small and big – some make big impact in the market – some don’t. Does it mean Product Managers are gamblers and work on something at random. Not at all.

Product Managers should have their ears on the ground. They should know the pulse of their users. Essentially a product walks with the foot of the Product Manager. Based on hours of interaction with users, analysis of vast data and knowledge of the market – a Product Manager comes up with what would be the next thing that would solve a (burning) 6155148915_7199307653_zuser/customer problem or improve user engagement. It might appear to others as mere intuition – but it is not; Product Management is not Astrology. However, such carefully acquired intuitions can go wrong and make a Product Manager appear more as a Gambler. Again – where the Product Manager’s skill comes into effect is to define what one will measure when the new feature is rolled out and what would be the minimal viable product to extract maximum learning. Essentially – “fail fast” – determine that something is not working and warrants no further investment or needs a pivot based on the learning. There is no gambling involved here.

A corollary of this argument would be when products/features are successful; the same Product Managers are termed visionaries.

Photo credits: Gil and William Cho

Product Management by Committee

One of the key issues that plagues a delivery team is having no Product Manager to guide the team. However, something that is more troublesome is having multiple Product Managers for a single product. This is what is sometimes referred to as “Product Management by Committee”. I am reminded of a scenario where a boat in a race had 5 people managing it and 4 people actually rowing.

Did you say “Oh, Come on..!! it can’t be that bad” ?

I personally feel that if you want to set a team up for failure, this is one of the things that you could definitely do.

Let us take a closer look at what the problems could be, with having multiple product managers.

Same goal, different priorities: Each PM tries to push his Agenda. Many times, each PM might have the same overall goal, but different priorities. They don’t want to contradict / confront each other. Often, they end up talking to some key resources in the team and pushing their items / enhancements without letting the other PMs know.

Collective knowledge or Collective confusion? There is a possibility that each PM has a different understanding to a scenario in the Product domain. For example, 2 PMs might have varying understanding of how an Insurance claim is to be handled when a car being driven by a person less than 25 years of age gets into an accident at a roundabout with a car driven by a drunk person. In such a scenario, the team would be chasing a moving target if they have to listen to both PMs.

Personality clash: PMs come in all shapes and sizes. Some are more technically oriented than others, some more forceful, some more knowledgeable and some more articulative. When you have a mix of such people providing directions, the team would be torn apart and staring straight at failure.

remix-monkeys-dance-clan-by-same-cc-by-sa-3-0

When Ted, my colleague took up the role of the Scrum Master for one such Agile team, this was one of the things that he identified as a failure factor. He set up a meeting with all 4 Product Managers and told them that henceforth the team would be happy to take inputs from all of them, however, all decisions and directions only from one of them. The PM committee now had to decide who that would be. They nominated Dave ( one of the key stakeholders within the PM committee) to be that person for the duration of the current release. This meant that

  • Dave would set priorities for the team and define the Acceptance criteria for each story.
  • Dave would resolve any conflict of ideas within the PM committee and provide direction to the Delivery team.
  • The Delivery team is not faced with various personalities with different agendas providing conflicting requirements. The team and PM have an opportunity to understand each other well and compliment each other for a successful delivery.

The team is now slowly increasing their iteration velocity, meeting most iteration commitments, gaining the trust of senior management and is able to enjoy their work. I believe this change has been the major factor in causing this turnaround.

Let us know what you think…

@SampathPrahalad

(Pic: Thanks to Remix Monkeys (A new creative look and Style on Urban Dance))

Does a PM know if a feature is over-engineered?

I often come across my Product Manager friends fretting about “over engineering” by their product development team. “Over engineering” leads to more time and money – which is a source of worry for the Product Manager. Does a Product Manager know if a feature is “over engineered” by engineering? Perhaps, Yes. Is the extent of engineering required for a product, a Product Manager’s prerogative? Perhaps, No. We love to state and perhaps over-state that Product Manager is also the complete owner of the product . Product Manager is of course the custodian of the business aspect of the product and has the say in what feature must go and the timeline of the feature. However, it is the engineering team consisting of software architects and developers who develop the product. Let us look at various scenarios based on two parameters: the scope of the product development and effort estimate. Continue reading

Interviewing Agile Product Manager

elephantTrust me, this has been most crazy of all interview rounds that I have been doing for quite some time now. Objective is to hire a product manager who has experience of delivering successful product release via agile methodology. Initially I felt that I am lucky to get so many CVs (candidates) with agile experience but as I started talking to these so called experts in agile, I started banging my head on the wall, and here is answer to WHY I did so.
Continue reading

Documentation updates in Agile Projects

Scrum and other flavors of Agile expect a potentially shippable product at the end of each Iteration or Sprint. This typically means that each user story within the Sprint has to be developed, integrated, tested, documented and made deployable to production. While this is not new, I have seen many variations to this in my experience with Agile teams. I am going to deal now only with the Release documentation part here. Everything else is out of scope for now.

Consider the scenario below.
In a reasonably small organization, we have the Product Marketing manager Laura who doubles up as Product manager of a desktop application GoldSpot that back-ends with a database server. Laura is responsible for pretty much everything on GoldSpot. She is always seen juggling and shuffling between business case evaluation, wire-framing, product backlog creation and constant prioritization, user acceptance testing, creation and updates to user and admin documentation, customer demos, marketing communication, etc. The product development team consists of 3 developers, 2 test engineers and a Scrum master. The team and Laura meet over Skype for the Sprint planning meeting, the daily standups, Sprint review and retrospectives. The team is in their third Sprint, have just created a prototype worth showing to customers and have 3 more Sprints to go in this Release.
Wanting to adhere to the practices of Scrum, the Scrum master asks Laura to update the User and Admin guides as part of each user story and each Sprint. However, Laura who is severely short of time, finds this to be an overhead to her. Here is her stance. “The product GoldSpot is atleast 3 Sprints away from the Beta Release and has a good amount of functionality and UI changes going in between now and then. If I make updates to the Beta documentation (User guide, Admin guide) in each Sprint, I will definitely have to revisit it in the coming Sprints and over write them when the UI or functionality changes. Also, I am the person who is providing demos to customers and know each feature well. I am showing GoldSpot to customers but not distributing it to them right now. In my backlog of tasks to do, I definitely feel that updating the guides is low priority and something that will move to the top of the list in the final Sprint or the one before that. This is like the customer communication or the training that we do when we get close to the Beta Release.”
I definitely feel that Laura has a point and while Scrum advocates a potentially shippable product at the end of each Sprint, it does not really go into the specifics of what makes the product potentially shippable. I have seen this model work well for Scrum teams where the Release documentation is written by the Product Manager or by a Technical Writer who is spread thin across different products.

Is it then time to take the “Release documentation update” activity out of the Sprint’s Definition of done? Or should we persist on getting it done in each Sprint?

Let me know what you think.