The product I manage is sold on a per-user basis. Most of our customers are small and only have a few users. However, there are a small number of customers who have a large number of users. The problem is that the needs of these large customers (who provide us with a good percentage of our overall revenue) are different than the smaller customers (who make up the vast majority of our users). If we focus on the customers that bring us the most revenue, we risk alienating the smaller customers (of which there are many). If we focus on the majority of our customers, we risk alienating the big customers (of which there are few). Who should we focus on?

Answer from Scott Sehlhorst of Tyner Blain: Thanks for the great question! Since the question is asked in somewhat general terms, I’ll answer generally. If something doesn’t match your exact situation, please follow up in the comments.

It sounds like you have two distinct market segments within your customer base. Small companies with a few users, and large companies with many users. Your comments about conflicting needs in the two groups tends to support my assumption. Remember that market segmentation is not just “what industry are you in?” but can be along any axis that allows you to aggregate customer needs / value / behavior.

Assuming this is true, I think you have to choose either to focus on one segment or the other, or consciously go after both. That strategic decision will (should) drive all of the rest of your decisions. You don’t provide enough data to pick one over the other, but the fundamental question is: “Which market segment is more important to my business?”

“More important” can mean any of a number of things. You might be focusing on market size (easy to do the math), or you may determine that one market segment has more potential to help your company grow. One market may be markedly more profitable than the other. Large companies can usually get more value from a solution that affects their business, thus generating more value (per company). If your product has high support or services costs, it may be more profitable to focus on a few large, expensive (to you), and profitable deals. If your product is very scalable, like a SaaS offering, with minimal incremental cost per customer, it may be more profitable to focus on a lot of small deals.

You may be exploring a blue ocean market, where the main strategic benefit to your company is in discovering the real value to your customers. More and smaller customers can give you more data points and can accelerate that learning.

The two markets may have a symbiotic relationship, where providing the solution to “the big guys” gives you credibility that reduces cost-of-sale to little guys. Or the reverse can be true. Being the visible “solution provider to everyone” may increase your ability to sell to the big guys.

Determine which market segment has the most value for your company and objectives, over the long term — and focus on that segment.

If you determine that both are important, consider splitting the product into two products (or versions) and/or splitting the team. Think of it this way: If the current team focuses on one market segment, is there enough value in the second segment to justify the cost of hiring additional people and providing a distinct product for the other segment? That gets you away from “we can’t do everything” as a knee-jerk reaction, and allows you to intentionally service both segments (or abandon the ‘lesser’ segment).

I hope that helps provide some guidance as to how to approach answering the question. This is a great strategic question, and I’d love to know more details if you’re allowed to share them. I’m sure the rest of Jeff’s readers would too.

I am a MBA student with an engineering background looking to pursue a career in product management. This question is about the certifications helpful to people with my profile looking to start in product management, particularly in boosting the intial career search opportunities.

Among the certifications from organizations like Pragmatic Marketing, AIPMM, 280 Group and others, what are the aspects I should look for in deciding about product management certification?

Answer from Scott Sehlhorst of Tyner Blain: I remember going to a stump-speech given by a congressional candidate in Fort Wayne, IN, about ten years ago.  After giving his pitch, he took questions from the audience. After every question, he would say “that’s a great question” and then he would say whatever he was going to say, which was not always an answer to the question. Sometimes I wonder if he meant “that’s a great question” in that it was great that someone asked a question that gave him a reason to speak.

As to the question of which certifications to go get as a product manager — that’s a great question.

When I’m interviewing a product manager candidate, I don’t care if he or she has any certifications. I care a little bit about what they know (what skills do they have), and a lot about what they will be able to learn.  Personally, I have the Pragmatic Marketing “practical product management” certification, which I believe is useful shorthand for “think strategically” and is a primer for discussion, but otherwise does not provide value. Their practical product management training is to this day the best single training class I’ve attended in any topic. I would place significant value on a product manager having the perspective that Pragmatic espouses, and being able to demonstrate their ability to apply it. Having the associated piece of paper is secondary. I’ll also add that I haven’t heard anyone I’ve ever worked with express that they “care about” certifications for product managers.

Great product managers understand their markets and customers. They can discover and value the problems and opportunities faced by the customers in those markets. They can prioritize the problems and their solutions to achieve a product strategy. They can pull that ‘big picture’ together into a vision and a roadmap. And they can communicate — both with customers and with internal stakeholders. A great product manager can lead people (note: I did not say manage, that can be useful, but is not always required) — because a product manager usually has ownership of a product, but not a team.

Are there any certifications that say “I can do all of that?” None that I know of. Can a product manager learn enough about the customers in a particular market, about the competitors in the space, and the team that will deliver success? That’s what I want to know.

Thanks again, and great question.

I have used a few different methods of writing Use Cases in the past but have the ability to start new in my new role at a new job. The Rational Unified Process is simply too much for my coworkers. I know writing a good Use Case is more than just the format, but can you recommend a good template or format — one that includes ‘alternate flows’?

Answer from Scott Sehlhorst of Tyner Blain: This is really a great question. As with many good questions, the answer starts with “It depends.” You point out that your team is resisting the RUP as being too heavy-weight. I’m going to answer your question in terms of both process and format – as they go hand in hand. I wrote about how to approach writing use cases as part of an agile project about a year ago, and that approach works really well in that environment. I’ve found since then, that it also works extremely well on non-agile projects.

The approach is designed to very quickly get an overview of the scope of the project – a “broad” view, and then to iteratively drill down into a “deep” view of each area of development until you have them all defined. This approach, even for non-agile projects, saves a lot of effort for the analysts and results in better use cases, written more quickly. The benefit comes from being able to incorporate feedback from each “deep dive” into both the broad view and the subsequent detailed views. There is an added benefit, when working in an incremental development environment, of being able to have the teams get started with the implementation of the most important use cases while the lower priority use cases are being defined in parallel. This allows you to compress the work schedule for the team overall.

Here are the steps you should take (after each step, allow yourself to revisit the previous steps as you refine your understanding of the product):

1. Define the use case names. Each name is in the form of subject-verb-object, with a clear goal implicit in the name.
2. Create rough sketches of all of the use cases. Identify the primary actor, and write a brief paragraph description of the use case.
3. Prioritize the use cases you’ve identified.
4. Create the informal use case (free MS Word template and tutorial after the jump) for the highest priority use case.
5. If needed or desired, create formal use case to stress the preconditions and postconditions, and to present the behavior as a series of steps. Some development and test teams need the structure, others do not.
6. Repeat step 4 (and optionally 5) for the highest priority use case that has not been detailed.

I’ve found, with experienced, local, development and test teams, that the informal use case format (linked above) is just as effective, with a lot less work, than the formal use case document. When outsourcing development, either the informal or formal document will be more effective – depending on the team. And to date, in every case with either inexperienced or outsourced or remote testing teams, a formal use case document is more cost-effective than the heavy amounts of clarification that are involved in explaining the informal format, and in reviewing the test plans that are created.

Good luck, and let us know how it turns out – or if you have had different experiences. Thanks again for the great question!