Saturday, December 20, 2014

Steve Johnson on Product Management




More notes from another
Business of Software 2008 lecture by Steve Johnson from Pragmatic Marketing.
He talks about what product managers' role is, what they actually end
up doing, and what they need to do, in order to be meaningful
representatives of the actual product's users.


  • Companies
    tend to start off as technology-driven, then become sales-driven (each
    new sale requires custom development), then become marketing-driven
    (lots of money spent on their brand image).
  • Then they cut costs,
    and go full circle to technology-driven, and repeat the cycle. Good
    product management can help to break this cycle.
  • Illustration of
    how wills are only executed: you are already dead when the will gets to
    court. So the document needs to be long enough to deal with all
    possible arguments.
  • Application specifications have the
    advantage that the specifier is normally still alive when the
    development teams come to implement them!
  • But we keep writing
    specification documents (product requirements, marketing requirements,
    functional specifications...) in order to cover all managers'
    worries/requests.
  • The right answer is not to create more
    artefacts. Tightening your grip will mean more slips through your
    fingers. Instead it's to have someone who really understands what's
    needed, and can back up their assertions with evidence.
  • Many
    companies are like Star Trek (original series): Spock (development)
    logical, trying to be human. Bones (marketing) upset about what he
    hasn't got, or what he's being asked to work with. Kirk (sales) always
    committing the ship to more than it can do. Scotty (product
    manager/sales engineer) lies to Kirk at all times, then says "OK, let's
    go!".
  • Agile development crowd wants to improve these
    development/specification processes by having a customer representative
    on hand to try out each iteration on.
  • Problem: most of us don't program for individuals. We program for multiple customers!
  • Agile/Scrum methods seem to make us more
    introspective. We spend so long in development team meetings that the
    product manager does not go out and talk to the customers!
  • Sales
    don't tend to understand why some of their development requests are not
    possible. An interesting idea is to turn this round and ask similarly
    unrealistic questions to sales. Example: "Why can't you give me a
    well-defined feature set by a guaranteed date?" is replied to with "Can
    you tell me what hour of the day and the exact amount that you're going
    to close this contract for?"
  • In many cases, the only people who
    talk to customers are technical support. But are they talking to all of
    our users? (Hopefully not!) They're only talking to the people with
    problems, and not even all of them. What comes out of this?
    "Remember the 'L' in (L)user is silent". "Losers" are those who you have
    to teach basic computing to. "Power Losers" are those who are trying to
    use your product in ways that you never intended. But you can't just
    try to market to "smarter" users!
  • Biggest contribution that a product manager can make is to be representative of users. That means the PM has to leave the building, and talk with users, and potential users!
  • Causing customers to switch is one target, but selling to potential customers is hugely important.
  • Three
    groups: current customers, evaluators (people currently shopping: only
    sales talk to them. If they don't buy, then product management analyses
    why), and the untapped potential market. The last group is very
    important.
  • Customers tell us what new features they want, but potentials tell us what would convince them to buy. Get evidence for what features are really asked for by customers. That helps choose which of the many ideas that come out of our company are to be implemented.
  • Development
    and Sales have different views of product managers should do. Sales
    tend to want people who can demo/explain the product. This is probably
    best done by sales engineers. (See Steve's post on sales people as order takers.)
  • Work
    out what areas of the business that are thought of as product
    management are not actually officially assigned to someone at your
    company: they will be happening, but are they happening well, or "just
    being done"?
  • Jargon: Inbound marketing is understanding what
    customers want the development team to do (product management). Outbound
    marketing is about actually selling the product (product marketing
    manager).
  • The product management triad: executive direction,
    marketing, and technical management. All require different skills. May
    end up splitting into three separate roles.
  • Sales people tend to
    think one deal at a time, which is as needed. But when sales comes back
    with a new idea, put it in the list of possible new features, but wait
    and see how many people actually want it, rather than just the one deal
    that that salesperson is currently progressing.
To me, it's
interesting how broad the role of product management can be. It's also a
salutory reminder that when two companies recruit for a position with
the same name, it might well be for totally different roles...

0 comments:

Post a Comment