Imagine gathering requirements as like fishing. You don’t want to catch every single fish in one haul as the processing of that would mean that some fish would go off. Focus on catching the big fish first by using a wide net, then later you can use a finer net to catch the smaller fish. This is the same with requirements as with the big requirements you can use them to understand the product direction better.
'The more user effort required to take an action, the lower the percentage of users who will take that action. The less user effort required, the higher the percentage of users who will take that action.'
Gestalt principles (1, pg 136)
Principle of proximity – the brain perceives objects that are closer together as more related than objects that are farther apart
Principle of similarity – the brain perceives objects that share similar characteristics as more related than objects that don’t share those characteristics
Visual Hierarchy Design Principle (1, pg 136)
The brain assumes larger objects are more important and smaller objects are less important
Elements with high contrast (e.g. items that ‘pop’) are more important
Position also affects visual hierarchy (e.g. for people who speak English the top left is the most important as that is how we read)
To determine visual hierarchy squint at the page you will be able to identify the most important design elements
Principles of composition (1, pg 137)
Unity – does the page or screen feel like a unified whole or a bunch of disparate elements?
Contrast – is there enough variation in colour, size, arrangement, and so forth to create visual interest?
Balance – have you equally distributed the visual weight (position, size, colour etc) of elements in your design?
Use of space – how cluttered or sparse does your design feel? Ensure there is enough white space so that it doesn’t feel crowded.
UX Design Iceberg (1, pg 116)
Conceptual design (1, pg 117)
This is the core concept you are using to design your product
E.g. uber’s is based around a map
Information Architecture (1, pg 120)
How the information and functionality should be structured
Findability – how easy it is to find what the user needs (test this)
Sitemaps are tool used to define the structure
Interaction Design (1, pg 123)
Specify user flows
What actions can the user take?
Including error messages and slow response flows
Flowcharts are a tool for mapping flows
Wireframes are tool for testing
Visual Design (1, pg 129)
Colours/ font/ graphics have emotions for user
Style guide used to ensure consistent feel
Layout grids used to ensure consistent alignment of the design (e.g. divide the desktop screen by 12 sections which is then used to put all the nav options/ content boxes in line with) (page 133)
What do we want to be in 5-10 years? Value for customers, position in market, what our business looks like
What business challenges are standing in the way of reaching our vision
Senior leadership Business leads
What problems can we address to tackle the challenge from a product perspective?
Product leadership team
What are the different ways I can address those problems to reach my goals?
Product Dev teams
Strategy Deployment Levels
Business Value Types
Framework for thinking about value by Joshua Arnold (1, pg 82)
Increase Revenue – Increasing sales to new or existing customers. Delighting or Disrupting to increase market share and size
Protect Revenue – Improvements and incremental innovation to sustain current market share and revenue figures
Reduce Costs – Costs that we are currently incurring, that can be reduced. More efficient, improved margin or contribution
Avoid Costs – Improvements to sustain current cost base. Costs we are not currently incurring but may do in the future
Type of Value (3)
Commercial Value: How much revenue or profit does this work result in?
Market Value: How many new customers will we be able to serve?
Efficiency Value: How much time or money will this save us?
Customer Value: To what extent will this decrease the likelihood that a customer leaves?
Future Value: How much will this save us in time or money in the future?
Project Rather than Product Management Smell
Build Trap (1, pg 1)
Build Trap = organizations become stuck measuring their successes by outputs rather than outcomes. […] When companies stop producing real value for the users, they begin to lose market share, allowing them to be disrupted.
Progress Focus Powerful Questions (2, pg 80)
For when a company is focusing on percent complete, status, or points rather than value
Could we achieve all of these measure and still be unsuccessful?
How are we validating assumptions about the user needs of the market demand?
What are we learning about value? How I this guiding our product decisions?
What has changed with our users or our competitive environment since we began this initiative?
Uses historical data with a statistical sampling method
Output is a range of possible future outcomes with a confidence level on that range
Embraces uncertainty of predicting the future
Asymmetric nature of software estimation errors (2, pg 203)
‘ There are known knowns. There are things we know we know. We also know there are known unknowns. That is to say. We know there are some things we do not know. But there are also unknown unknowns. The ones we don’t know we don’t know’
Former Secretary of Defence Donal Rumsfield
Estimations are more likely to take longer than expected than they are to take a shorter amount of time than expected (i.e. they are asymmetric)
Developers estimate based on known knowns, and sometimes known unknowns.
Some error comes from misunderstanding these
Most comes from unknown unknowns
Larger tasks are more likely to have more unknown unknowns so the risk of rapidly increasing is much higher
Cone of uncertainty shows that the likeliness of under as over-estimation is symmetric