Note: These notes were taken live, so there will be gaps, grammatical errors and other mistakes.
10 Lesson I Learnt the Hard Way
Pip Jamieson (@Pip_Jamieson)
Founder, The Dots (@The_Dots_UK)
“I’ve seriously fucked up along the way.”
1. Hire happy positive people
- Team is the most important thing in building a product.
- People who look good on paper might not be right for your business.
- “I want people to come to me with solutions not problems.”
2. Don’t be afrtaid to work with people offshore
- Competing with Google, Facebook and other big companies for talent.
- Development team based in Sri Lanka. They’re amazing. Zero attrition.
- Product & design are in-house, but dev is offshore.
- Tools: Slack, Jira, invision
3. Keeping a team
- “I’ve lost staff because I’ve burnt them out”
- The chart is great: performance, arousal, Panic Zone
- You can push a team too hard
- Team can’t work on the weekend
- They have to leave at 7:00
- Constantly getting the trained up
4. Building a product driven culture – meet users
- When they actually showed the interface to creatives, they hated the look and feel
- Surveys: typeforms
- What I find with surveys is that people recommend changes to twhat they see. Chatting with users results in finding out what people’s challenges actually are.
- People go to word mouth when hiring. Talent is important, but cultural fit is more important.
- We would never have known that if we hadn’t just listened.
5. Building a product driven culture – hn
- Team is so passionate that the idea flow is so overwhelming
- We can’t build everything
- Internal pitch days every two months
- If people have come up with a great idea they put them in a folder. Every two months they choose their best two ideas. Pitch for two minutes. Team discusses it for two minutes.
6. Prioritising ideas
7. Down and dirty testing
- Lots of ideas, but some are shit
- We get people in every week to see how they are using features.
- Tools: hotjar for heatmaps, tableau for data collection (pulls in data from analytics, back end, accounting software)
8. Design rules!
- People expect beautiful things now. They expect usability.
- invision: prototype and show to users
9. Product development – 5 whys of mistakes
- Try to get to the core of what the problem is
- Site went down for two days. Root cause: not robust enough testing or robust enough go-live process.
10. Celebrating the wins
- Glory wall (not a great name)
- Feedback from users, great places we’ve found, good talking point for when investors come in
Designing a Better Onboarding Process
James Gill (@JameJGill)
1. What onbaording entails
- The management of the early stages of a relationship between a business and a customer. (Collins dictionary)
- Onboarding is hard.
- (missed his definition)
2. Ways to improve
- Think about the staes of our app: Awesome screen, but also Empty and Error states.
- Onboarding is a flow.
- Sign-up —> Homepage —> Empty —> Full-on awesome
- Examples: Developers vs. Marketers
- Onboarding needs to not piss off either of these users
- Reduce the # of steps
- Get to Wow ASAP – focus on the important stuff
- Every step in the obarding process is a hurdle
- Set sensible defaults – It’s easy to push decisions off to the user, but it’s lazy product management.
- Gamify – Think about how to get people to do things, though not necessarily in their first session
- You don’t need to offer a reward, just having checklist is enough
- Emails are part of onboarding
- Make the relevant
- Don’t send too many
- Deliver happiness – don’t just spam people
- Notification (Slack stops sending emails and automatically sends push notifications.
- Set up a weekly task to sign up as a new user
- Measure onboarding
- Good metrics are actionable
- Define successful onboarding (Install traffic code and sees traffic spike)
- Chort analysis
3. 3 examples
- Sunrise – two steps (both because of Google) and you’re there
- Apple Watch – push the onbarding into an app, most beautiful QR code
- Slack – only ask for an email address to sign up, then get you to fill in your profile by using Slack
- Marvel – prototyping
- Olark – live chat
- Drip – very nice onboarding emails
- AndrewCne.co – see “The next feature fallacy”
Where Do Good Product Roadmaps Come From
Will Swannell (@wswannell)
Founder & CEO, Hire Space
- A product roadmap shows how a product is likely to develop.
- It aligns stakeholders and allows effective planning.
How to present your roadmpap
Five things that a good roadmap has:
* Transparent and accessible
* Can have regular attention brought to it
* People can leave easy feedback and engage with it
* It should be limited in size
* Can be quite easily editable, torn down – set the expectation that this is where we are likely to go
What should go on a roadmap?
- Is it big?
- Is it something that everyone really, really needs to know about?
- Is it going to shift a KPI in the next 4 months?
- Is it scalable?
How items get (and move) on a roadmap
- Stakeholders – Team, users/customers
- Time – Get stakeholder and devloper to give it a number in the fibonacci sequence to estimate this
- Data, e.g. dropoffs in different funnels across different cohorts
- Decision maker – voting, but groupthink can make bad product decisions, each product should have a single owner
And end-to-end example
- Venue Groups, e.g. Oval Space has a sister venue: Pickle Factory
- You can wind up with two users who are managing related spaces.
- #1 customer service ticket – “What’s my account?”
Product’s Perception And The Needs of Its Customers
Karolis Kosas (@karoliskosas)
Creative Director, YPlan (@YPlan)
- Too many things to do in London, but people don’t plan.
- Couldn’t cater to everyone with three events, which is what the original app had.
Adding more events meant it wasn’t reliable, so the decision was made to add structure (move from a corner store approach to a Sainsbury’s approach). What was needed was something in-between these two.
Intent – predict the intent of people going out.
Resulted in Categories: Date night, going out with friends, Sunday Brunch, Stay Dry, Free culture
People like the quirky and niche things they find on Yplan because they can show off to friends.
- But the data showed that mainstream was the bulk of the tickets sold.
Added a website to pull people in to the big stuff.
A lot of customers say that don’t plan a week in advance.
Not true for bigger events, they book to get the best deal and are flexible with the dates.
For events like theatre, it’s not about the cheapest price, it’s about the value for money (e.g front row vs. sat behind a pillar).
Reliable supply – the more supply you have the better the conversion is going to be.
Design at SwiftKey
VP Design, SwiftKey
Three components to design at SwfitKey
- UX Design
- Visual Design
- UX Research
(Skipping copywriting, motion design that they do as well)
- 1 VP Design
- 2 Senior UX Designers
- 1 UX Designer
- 2 Associate UX Designers
- 2 Visual Designers
- 2 UX Researchers
- What did you do yesterday?
- What are you going to do today?
- Do you need any help?
People used to go into gory detail about what they did, but these questions can avoid that.
Co-seating with Engineers & PMs
- Design sits together, but there are hot desks amonghts the engineers and the product managers
- Swim Lanes
- Typing Experience
- Visual Design
- To Do
- In progress
Weekly Sprint Demos
- This is when the engineering team shows what they’re working on
- If people aren’t pulling their weight, it shows. So does doing extra.
- Demo wall gives everyone the opportunity to know what’s going on
Visual Style Guide
- Borrowed Google’s style Guide
- Built their own style Guide
- Documents patterns, but not every bit of design
- Brand isn’t logo
- Tone of Voice
- Graphic devices
Co-Founder & Head of Product, OneFineStay
Defining your culture
- Very nebulous thing?
- More than ping pong tables in your office
- “the way a collective of people make individual decisions”
Types of culture
- Product-driven (Apple) – Make what customers want you to build
- Customer-driven (Amazon) – Make what your customers want
- Engineering-driven (Google) – Sell what you can build
- Sales-driven (Microsoft) – Build what you can sell
Communicate the vision
- They made 6 motivational posters for their cultural values. These didn’t really work.
- Instead, they distilled it into values:
- Heroism. Go out and be with the customer if they’re having a problem. You end up taking people who hate your product and you turn them around.
- Craft (data-driven development) – Focus on taking people who are interested in your business and making them more interested in the business. This makes sense for later stage businesses.
Embed it with process
- use process, to enforce cultural habits that overcome decision fatigue
- Confirmation bias (issue for customer-driven cultures) – A tendency to seek evidence that agrees with our position. Looking for data to support your hypothesis. You should also be testing an anti-hypothesis when A/B testing.
- Authority bias (issue for product-driven cultures) – Tendency to over-value the opinion of those who are seen as an authority on the subject. OneFineStay does Crazy Eights: get people who are working on the problem to do eight different versions, no matter how crazy they are.
- Bandwagon bias (issue for sales-driven cultures) – Tendency to do things because many people do the same. If you have to do something because CEO makes you do it, test it.
- Overconfidence bias (issue for engineering-driven cultures) – Tendency to belive ourselves less likely than others to experience negative life events. “I can do it better than anyone else.” Use prototyping to test ideas.
- Who’s driving?
- What is your focus, right now?
- What processes do you need?
- DO IT!
Putting People At The Heart Of Government
Anna Wojnarowska (@voina)
User Researcher, Government Digital Service
- Digital (gov.uk)
- Technology (Anna sits here)
What’s the need?
- Gov’t IT spending is 1-2% of GDP.
- 4 million desktop computers in UK gov’t.
- Some teams mark slow hot-desking computers with black dots.
- GDS wanted to show that procuring computers for people could be done differently.
- Technology at least as good as people have at home.
- GDS says that user needs are more important than government needs.
- Civil servants are users, too.
- Anna was told to find out what it meant to be a civil servant
- She has a digital anthropology background, so she wanted to go do ethnography for a year, but couldn’t.
- Agile – need to go test things with people and report back.
- User research as a team sport – every member of the team needs to understand users in the same way. She couldn’t go along. Other people came with her when she was doing interviews with users.
- GDS approach
- Build empathy – understand who the people are that you are delivering to. Cabinet office seen as young people who would welcome change. GDS actually seen as a threat. Used personas to understand people. Personas were completely detached from roles.
- Break artificial divisions – People saw technology needs in terms of roles. Instead, GDS focused on what people need based on their context. 7 different profiles (probably too many).
- Make the information useful. – e.g. Found out what percentage of the population each of the 7 profiles were. Useful for those who needed to supply devices to these people.
- Mobility or flexiblity?
- Look holistically – Think more broadly than just introducing change into one organisation.
- Tailor innovation – Don’t just introduce a new device because it’s new, but because it is better for you. Also ensure that people know how to use the device.
- Develop skills – Instead of investing in new technology, think about what new technology will do to users. What are the skills gaps, and how can they be addressed? Development is something that civil servants struggle with. They often leave the government because of this.
- “It’s more than a device” – Change does not have to be limited to technology. Change in process can address the core of the issue.
My journey to Data-driven product
Graham Paterson (@GPat_UK)
Product Manager, Intuit
Data is more than just traffic and conversion
- How TransferWise does product: It’s not the leadership team that decides what to do. Every product manager decides what they want to work on.
- No one is ever wrong, they just have access to different information.
What is data-driven product design
Three key aspects:
* Delight (e.g. NPS, return rates, social media sentiment)
* Impact (What improvement have you had to your customer’s lives?)
* What to do next
Focusing relentlessly on your users
- When I was building products, I was doing it for myself.
- Divorce yourself from the process and focus on the metrics. Are they improving for your users?
Two types of data
- Company-based data
- Focus on customers (focus on customers)
- Important to store this in one place, so you can build up a picture of your users.
Segment as much as is relevant
Example: NPS score started going down. Panic. Looking at the data revealed that score stayed the same in UK, but was lower in areas where the company was growing.
- Solve for one person
- Solve for their segment
- Solve for more segments
Data for roadmap ideas
- User feedback
- NPS surveys
- Your sales team – they have greater customer empathy than anyone else in the company
- Customer contacts
Customers will tell you…
- People will offer suggestions about how to improve your product.
Good data means testing quickly
- You can quickly test improvements
Research For The Rest
Rachel Ilan Simpson (@rilan)
UX Designer, Google Chrome Team
Creating the surface between a person and the piece of code that does something for them.
Sense of resistance to doing user research in startups and large companies.
“User research” sounds daunting.
* How does it tell you something that a survey won’t?
Talking to users is scary.
* Gets scarier the further along you are in the development process.
User testing allows you to course-correct sooner rather than later.
Let’s know what to make and how to make it.
Each step of the way
1. Identifying user needs
2. Meet those needs
3. Iterate the idea
4. Are people using your product?
User research is more than a report – It shouldn’t just inform your product, it should change it.
User research should be the backbone of the product. Best way to do that is to bring in the whole team.
To do this, you need to tell stories.
User research is about empathy. It’s in light of this empathy that a team will understand why they need to make changes.
- Intercept interview – short interviews done in a public space with a wide range of people.
- In-home interviews – longer interviews done in the home.
- Card sorts – set of cards with themes to be sorted into categoreis.
- Usability tests – putting a user in front of your website and seeing what they do.
Trip to India
- Communicated insights in terms of stories of real users.
- Connecting user needs to the product.
- Created prototypes based on insights & tested with remote user testing.
A less daunting method – pulse testing
- Run a usability test with a small group of users every two weeks.
- Rocket Surgery Made easy has a similar process. Four hours every month, including a lunchtime debrief.
What users are thinking when they use your product (according to Seth Godin)
- What is it? (Very important.)
- Do I trust it? (Judgement made in the first few seconds of using your product. Ask them: what does this remind you of?)
- What is it offering me? (Clear proposal of what that is.)
- How do I get it? (Call to action.)
Research isn’t something you do.
It’s something you practice.
Evangalize your insights
Use pictures, stories and videos as much as possible.
Make real change
Every user testing session is an opportunity to change something about your product.
Start with low-hanging fruit and go from there.