Product Management

1. Product
Managementby Attila Ulbert
It does not matter how good your engineering team is
if they are not given something worthwhile to build.
-- Marty Cagan (Inspired)

2. Introduction
Product management in 1+2 slides

3. Why we Make Mist4keS?
● It is my child!
● Who are you and what do you want?
● Do you really do it this way? I thought I know you…
● Why didn’t you tell me!?
● Why did you tell me!?
● Are you fine with it? I thought you were interested!
● You are all important to me!
● I/you/we must have something misunderstood!

4. PdM in a nutshell
● Product discovery:
● Identify the minimal possible product that meets the objectives
minimizing time to market and user complexity.
● In collaboration between PdM, interaction designer, SW architect.
● Minimal successful product:
● The product must be
● valuable,
● usable,
● and feasible.
● Cannot be piecemealed and expect the same result.

5. Principles
● UX is important: interaction and visual design.
● Think in conceptual models (users do this).
● Functional requirements and UX design are intertwined.
● High-fidelity prototype for testing ideas.
● Test product ideas early and often on actual target users.
● Exclude own emotions in product discovery.
● Focus on the emotions of the customer/user.

6. People
Some people see things that are and ask, Why? Some people dream
of things that never were and ask, Why not? Some people have to go
to work and don't have time for all that.
-- George Carlin

7. Product manager
● Responsibilities:
● Opportunity assessment
● Defining the product
● Discover the solution: Describe functionality and behavior to be built, and not
how it will be implemented.
● Has to know the target market.
● Attitude
● CEO of the product.
● Full responsibility for the product, does not make excuses.
● No micromanagement.
● Quick to take the blame when something goes wrong.
● Quick to give credit to the rest of the team when it goes well.

8. Product manager – skills
● Applying Technology
● Be comfortable enough with the technology.
● Understand new technology and see how it might be applied to help solve
a relevant problem.
● Focus
● Focus on the key problem to be solved at any given moment.
● Reduce the number of cluttering features; reduce the time it takes to build
the product.
● Time management
● Quickly distinguish which is important from which is urgent, prioritize and
plan time appropriately.
● Focus on those tasks that are truly important for the product.
● Communication skills
● Effective speaker and writer.
● Influence others by persuasion rather than authority.
● Business skills

9. UX, PM, Eng
● User Experience Designer
● Interaction designer (aka UX architect).
● Develop a deep understanding of the target users.
● Task, navigation, and flow that are both usable and productive.
● Project Management
● Project scheduling and tracking.
● Engineering
● Build and maintain the product.

10. PdM and engineering
● Use engineers:
● Get the engineers in front of users and customers.
● Brainstorm the different technologies that are available or coming
available.
● Involve the engineers from the very beginning in product discovery
process to get early assessment of costs.
● Helping engineers:
● Keep the focus on the minimal product.
● Minimize churn once engineering begins to develop the product.
● Answer the questions of the engineers.
● Avoiding big-bang rewriting: give 20% of the team to engineering to
spend as they fit (re-write, re-architect, re-factor, etc.)

11. Managing by objective
● Never tell people how to do things. Tell them what to do, and they will
surprise you with their ingenuity. -- General George S. Patton, Jr.
● Customers and users try to tell how the product should work;
however, there are many possibilities to solve a problem.
● Customers and users aren't in a position to come up with the best
solution.
● A PdM shall not tell the UX designers and engineers how to do
something, rather what the product needs to do.

12. Process

13. Product Opportunity
Assessment
● Prevent company wasting time and money for poor opportunities.
● Focus team and understand what will be required.
● Shall answer the following questions:
● Exactly what problem will this solve?
● For whom do we solve problem?
● How big is the opportunity?
● How will we measure success?
● What alternatives are out there now?
● Why are we best suited to pursue this?
● Why now?
● How will we get this product to market?
● What factors are critical to success? (solution requirements)
● Given the above, what’s the recommendation? (go or no-go)
● Do not speak about the solution, just the problem!

14. Product discovery
● Build the right product:
● Welcome and explore new ideas,
talk with scores of users and
customers.
● Product concepts and test them.
● Start with prototyping.
● Bad practice: start working with the
whole team and use the customers
as unwitting test subjects.
● Engineering team:
● During the discovery: the whole
team is not needed.
● During the execution: keep the team
on track.
● Churn:
● the product spec continue to change
in significant ways during execution,
and impacts execution
● Results
● release date is pushed out
● features get cut
● quality gets compromised

15. Product principles
● Purpose:
● decide what is important
● bring together the product team, and get the team on the same page
● What is important (and incidental), what is strategic (and what is
tactical and temporary).
● Prioritize them (e.g. security, ease of use, …)
● Example (movie site): user community’s opinion on movies is more
important than those of professional reviewers.
● Mistakes:
● too generic and not usable principles
● confused with design principles

16. Charter user program
● Reference customers.
● Opposing goals:
● deep understanding of target users is needed
● but there is no time to work with all of them
● At least 6 users.

17. Charter user program – The deal
● Benefits to the customer:
● get early and significant product input
● early access to the product
● Benefits to the PdM:
● users available for ongoing questions and dialog
● customer deploy test versions and provide timely feedback
● if they are happy, they serve as a reference customer (helps
marketing: success story)

18. Charter User Program – critical
points
● The numbers of the charter users program must be right set (not too
many, not too little).
● If customers aren’t interested, the product might not be interesting
enough.
● They must be from the target market.
● Don’t try to build a custom solution; the goal is a general product;
charter users must be explained this.
● Charter users are development partners, they shall be treated as
colleagues.
● Close interaction; show them prototypes; engage them.
● Release software to them before the GA, and make sure that they are
happy with it.
● In case of a platform product: end the program with 6 reference
application (and not user)

19. Personas
● Persona: archetype description of an imaginary but very plausible user.
● Goal: Understanding the target user to evaluate trade-offs and make decisions
● Creation of personas: collaboration of the PdM and the interaction designer.
● Benefits:
● Help prioritize what’s important.
● Help the PdM not to confuse himself with the customer.
● Prioritize different type of users, and help realize where a separate user experience is needed.
● Describe for the product team, who is the product for, how they will use it, and why they will care.
● Rally the team around the common vision.
● Pitfalls:
● Personas are not prioritized (product is not for everyone); PdM shall focus each release on a
single primary persona.
● Personas are created based on assumptions and stereotypes and not verified that the theoretical
persons really exist.
● Prototypes testing: only personas are participating (a range of possible users shall be recruited).

20. Product specification
● Good product spec:
● must include the full user
experience: interaction and visual
design
● represents the behavior of the
software
● the behavior must be communicated
so that engineering, QA, customer
service, marketing, site operations,
sales and executives understand it
● must be up-to-date
● single representation (i.e.
document, model, etc.) including all
artifacts (mockups, wireframes, etc.)
● High-fidelity prototype
● It should be done rather than
writing a 50-page word document
that very few read.
● Supplements to the prototype:
● business logic
● release requirements
● platform delivery requirements
● use cases

21. High-fidelity prototype
● High-fidelity prototype:
● realistic representation of the proposed UX
● can fake the backend processing and data
● Must be tested: put it in front of actual target users and ensure
● usability
● usefulness (value)
● If it does not pass the test, the development shall not be started.
● Shall be done iteratively: after testing it, it must be modified according
the user feedback!

22. High-fidelity prototype – benefits
● Engineers get an unambiguous “specification”.
● QA know the expected behavior.
● Can be used for reporting to execs.
● Minimizes time to market:
● Typical spec is poor, and hard questions/critical details are not
addressed and resolved.
● Engineering team must tackle the issues → results in “churn”, or
the engineers make ad hoc decisions

23. Product validation
● Have evidence that the product will be successful before building out and
deploying the product.
● Evidence of valuable, usable and feasible.
● Feasibility testing
● Whether or not the product is going to be buildable → investigating technologies.
● Technical risks.
● Usability testing
● Often uncover missing product requirements.
● Based on the prototype.
● Value testing
● Do the users find the product valuable?
● Typically combined with usability testing.

24. Product
Don’t love your product. Love your customers.
-- Hurricane

25. Specials
● Special: build a product for a single customer.
● It is dangerous to rely on a single customer, can derail the product.
Cannot follow the market changes.
● How to avoid:
● Explain the problem in terms of the solution the customer can understand
rather than the underlying problem itself. Help the customer to tease out
the core issues and needs, and help them to provide an even better
solution.
● Keep the product general purpose, and allow it to be
customized/extended.

26. The new old thing
● New incarnation of something old.
● Two key methods:
● Understand the target market. Usability testing is an excellent
technique.
● Realize that what is possible is always changing: new
technologies.

27. Emotions
● People buy and use products largely for emotional reasons.
● Dominant emotions
● In enterprise: fear or greed. “If I don’t buy this product, my competitors will beat me
to market, etc.”
● In customer space: emotions are more personal, e.g. loneliness, love, greed, pride.
● Learn the users’ emotions in prototype testing.
● Identify and prioritize the dominant buying emotions. Then figure out where
else they might be able to get that need met.
● Look for anger, exasperation, and frustration: solve on the most miserable
thing people have to deal with, and solve that problem!
● Talk in terms of users core needs or emotions!

28. Emotions – adoption of technology
● Lover (find technology cool): these people are dangerous for PdM, as
they have different needs than the larger population.
● Irrational (early adopter): have same emotions as the larger
population, but with more intensity (often negative emotions: fear,
anger, loneliness, …); their buying behavior is not economically
rational
● Exaggerate the value → teach the PdM of the value of the product.
● Efficient (early majority): adopt when the technology becomes
practical; pragmatic about benefits vs costs.
● Laugher (late majority): same emotions, but more muted; they don’t
want to deal with grief to get benefits
● Comfortable (laggards): want the benefits, but has to be drop simple
● Assessing emotions: freshman test

29. Keys to enterprise products
● Usability
● Product actually needs to work, no customization shall be needed.
● Beware of Specials.
● Customers and Charter User Programs.
● Designing for the sales channel.
● The customer versus the user. (Different types of end-users: system
administrators, management, etc.)
● Product installation: bulletproof to install.
● Product configuration, customization, and integration.
● Product update shall be smooth.
● The Sales Process.

30. Worry list
● Is my product compelling to our target users?
● Have we made our product as easy to use as humanly possible?
● Will this product succeed against competition?
● Do I know customers who will really buy this product?
● Is my product truly differentiated?
● Will the product actually work?
● Is it a whole product?
● Are the product’s strengths consistent with what’s important to our
customers?
● It the product worth money?
● Do I understand what the rest of the product team thinks is good
about the product?

31. References
http://svpg.com/