What I hear often in product companies

Here is what I often hear in product companies. Guess which is the most common one?

  1. I want the confidence that my product goes where we want it to go. I don’have it today.
  2. The product does not sell! What’s wrong? How to fix that?
  3. The product sells but not enough in this segment
  4. Going up (or down)market: what the product should be like? How much it will cost me?
  5. Going global: what the product should be like? How much it will cost me?
  6. Need guidance for the next generation of products. We have a new vision to achieve. We need help
  7. How do I make sure that what we are building is right? We have invested a lot!
  8. Is there a way to tell whether my requirements will deliver against the expected product?
  9. Is there a solid, simple way that is able to tell my company “you are following the right direction” (or  at least the one you have decided to set)
  10. How to build roadmaps that serve business goals? (vs. good-looking, time-consuming slideware with unrealistic, wishful milestones ?)
  11. Marketing people produce tons of sales tools, brochures and presentations. But my sales people say “they are useless” and don’t use them. What’s wrong?
  12. I want that my sales people sell what we must sell, not what it is easiest for them to sell, and I need marketing to support that.
  13. There are a lot of ideas, inputs from sales and pressures from individuals about “top, critical priorities”. Or… “we won’t sell without this or that”. I want to make sure we do the right product for the business. I want clarity.
  14. We spend a lot of time debating features with development. Often it sounds like a war between opinions and I am not able to help much. I want to make sure we have someone driving our offering for measurable benefits for my business. I do not want fights!
  15. We spend way too much energy toward several directions without getting the expected results, our competition is killing us. Time for change. but.. change what? Where do I start from?
  16. Every decision we make is an ordeal. Not to mention fights, politics and internal wars.  I want my line managers to be more aligned, efficient, with clear, shared goals in mind (the same ones).  A sort of “autofocus” mechanism that points to my business’ priorities
  17. I need a methodology that allows me to make informed, intelligent decisions that do not take into account personal agendas and internal politics

What are the ones that are more familiar to YOU?


“Request” and “Requirement” – the difference

Sometimes a customer requests a functionality. As an example, because she runs into a problem while interacting with the product. This is more serious when it happens often, when it prevents to accomplish critical or important tasks or when it forces time-consuming and error-prone workarounds.

In this case we are talking about a CRM-Like software, that is a software that every sales people and customer support org uses every day. It could be any enterprise software.

The customer says:

¨I want to sort alerts by sender.  I need to sort by attributes.  Sender must be the first column. How is it possible you cannot sort alerts?
We understand what she says because we know well our product. What we don’t understand however, is WHY that is such a big deal for her. WHAT is the problem she wants to solve in its essence.
Then we interview the customer and we get a totally different perspective
¨Tina gets many alerts but she only needs to know about the ones requiring action on her part so that she does not miss important ones by browsing among hundreds of them, every time”
Can you see the difference?
So, what does this example tell us?
  1. Customer was telling us the solution – We are the experts of the solution, not them.
  2. There could be many possible solutions , some much better than others for both us and the customer.
  3. Customer is the expert of what’s the problem he needs to solve. We need to capture that.
  4. Customer often has a narrow perspective, focused on his problem in a specific day on a specific scenario. It’s normal. We should *never* expect they write requirements for us. They are simply not good at that.
  5. We need to elicit the root cause of the problem. This may require meaningful interviewing skills/methods.

If we don’t do so, let’s not be surprised if we hear things like “The customer said that the feature does not resolve his problem. But we did what he asked for!”

User Personas for… sales ??

The power of User Personas in modeling requirements and building products is well-known (never enough I’d say, but it is known).

I extensively use the incredible power of buyer and user personas (ala Alan Cooper) in the entire product life cycle with consistently excellent results.

The other day I was writing a positioning document, a functional overview for a new product and, while I was at it,  a product datasheet.  I asked myself: “why shouldn’t we  use  the same user personas we developed for designing the product to illustrate product benefits and functionalities?”

And so we did.

I mean, content for customer facing documents. I have used personas several times for design and building products with great success, but never for actually customer-facing documents.

Not only it worked like a charm. I realized then that even our demo guys used the personas we developed for their product demos. Salespeople were also referring to personas when explaining our new solution to customers.

Personas are the most powerful tool you may use in designing, building, marketing and selling products. Period.

What is a Requirement?

What is a Requirement?

check this out at http://bit.ly/q2cyZz

Requirement Describe a user (persona) interacting with a product to resolve a problem. The following format has been proven to be very intuitive and effective:

As a <Persona> I want to <Intent> so that <Valuable>

Example 1

Todd wants to share his design (in form of a sub assembly) with suppliers for a prototype run. He need to generate automatically specific file formats (PDF and IGES) from his many 3D CAD models so that he can save time and distraction from his core engineering tasks.

Example 2

As a technical reviewer I want to access the information I am asked to review in an univalent manner. I don’t want to fish for the files need every time, So that I have the required time to review them before submission and save costly errors

Related articles:

Good Requirements Relate to Business

Il CEO ed i suoi diamanti