From Todoist’s Year in Review:
Here’s to getting up early!
From Todoist’s Year in Review:
Here’s to getting up early!
I don’t normally think much of lists of productivity tips, but I quite liked this list from Quartz: Ten things to do on weekends to make your Monday more productive.
The article starts with the oft-quoted statistic that productivity declines rapidly after more than 55 hours per week:
“The study found that productivity per hour declines sharply when the workweek exceeds 50 hours, and productivity drops off so much after 55 hours that there’s no point in working any more.”
So if you’re not working all through the weekend, how can you use that time to give yourself the biggest productivity boost come Monday?
Most productivity “hacks” are nonsense, but I found myself agreeing with nearly all of the recommendations on this list. Particularly:
With so few hours in the day, where you spend your time has a huge impact on your overall success, and reactively moving from one thing to the next is the best way to fill lots of time with being busy and not getting much done. Take the time to step back, reflect and plan.
At the recent FATMAP Christmas Hackathon, one team set out to make it easy to be inspired by the outdoors every day, even when we’re sitting at our desk.
The new FATMAP Chrome browser extension gives you a new adventure inspiration, every time you open a new tab.
It’s free, and you can get it from the Google Chrome Web Store.
Access to high quality resources for product management is better than ever before. There are so many excellent people writing about product management that it’s easier than ever to find the knowledge that you need.
So why are there still so few product teams actually working in the ways described in all of these resources?
When I talk to other product people, I see the same thing again and again: Most PMs can talk convincingly about the benefits of and process for anything from customer discovery techniques, growth accounting, data driven validation, lean startup techniques, etc etc. But when I dig deeper and ask how much of this stuff do they are actually doing, the answer is too often something along the lines of “oh, we haven’t really started that yet.”
I call this the knowing / doing gap. 1
Knowledge about great product management practices is cheap. It’s available everywhere online and in countless books… knowledge is no longer your competitive advantage as a PM. Your competitive advantage is in actually doing it – and doing it well.
Why don’t more product teams do the things they know they need to do?It turns out it’s very easy to know you should be doing something, but then not do it.
Why is this? Aside from the psychology of procrastination, I have a few theories:
Doing customer interviews for example requires you to go outside the comfort and safety of your office and talk to real people. Many people find that really hard… but with customer discovery, it’s as unlikely as ever that the right answers are in the building.
It’s easy to fall into the “we don’t have time to validate this” trap. Running a usability test on this prototype might take a few days, and we need to ship it next week! If we validate it we’ll be late!
It’s true: validating something, from a product idea to a user flow, takes time. But would you get behind the wheel of a race car if the mechanic told you, “we didn’t have time to test the brakes or the steering”. I wouldn’t; but that’s what you’re doing when you plod ahead shipping production code for an idea that’s never been validated.
One of my favourite quotes from Peter Drucker is:
“There is surely nothing quite so useless as doing with great efficiency that which should not be done at all.”
I wrote about autonomy recently after Marty Cagan did a talk on the topic here in Berlin.
When teams are set up to deliver the feature list as proscribed by a Head of Product or CEO, then validation work feels useless. The ultimate success or failure of the product rests with the CEO. Right?
Well; I always argue to people in this situation that the best thing that you can do is run the validation anyway. Bring your findings to your Head of Product or CEO and discuss them. Either they will applaud your initiative and encourage you to run more validation; or they will deny the results and tell you “we’re doing it anyway”.
(If the response you get is the second, I would encourage you to find a new company.)
At the end of the day, there are seldom really good excuses for not doing better customer discovery and product validation. Resources and knowledge are plentiful. The only thing that’s holding you back – is you!
A simple way to start building a validation mindset: every time you find yourself looking at a product feature or solution you’re planning, force yourself to step back and ask these questions:
A validation mindset is all about moving from “I think” or “I believe” to “I know”. The first step is just asking the question: “How do I know?”
At FATMAP we celebrated Christmas last week by getting the whole company together for two days here in our Berlin HQ.
We started with a one-day Hackathon. We started with idea proposals, and teams quickly formed around the most interesting and creative ideas. There was only one rule for a hack day proposal: you had to be able to tell us how you were going to measure the result. If you can measure it, it was fair game.
The results of the day were some incredibly creative and interesting ideas. Among the projects:
The best thing about a Hackathon day is the energy: the room was full of it and teams were busy hacking, discussing and working together.
You always wonder: why isn’t every day like a Hack day?
My theory is that hack day teams work well together because:
We’re making some changes to how we work in 2019 to make it easier for teams to work more like Hack day teams. We’re shifting the FATMAP Product Roadmap to be more focussed on prioritised and validated user problems, rather than a list of features. (Much has been written about problem-based roadmaps; this is a good start). And we’re focussing more on building autonomous, cross-functional teams that can deliver product value end to end.
We strongly believe that small, autonomous teams with a clear, aligned vision build better products – and this week’s Hack day has definitely shown that.
Note: the photos from this article were taken by our Community Manager, Jon Williams.
When Reid Hoffman talks about building a startup, he says it’s like jumping off a cliff, and assembling a plane on the way down. It’s a reference to the fact that when you start building a startup, you set a clock ticking.
If you can find product-market fit and a viable business before the clock runs out, your startup has a chance of success. If you can’t, then you’re in for a hard crash landing.
That’s why for startup product teams it’s critical to move as fast as you can. The most valuable resource you have is time, so you need to be extremely wise with every hour you and your team spends.
The key to moving fast is not to work harder, but work smarter. It’s not about working weekends, skipping lunch or pulling all-nighters. It’s about making smart choices about how to get things done.
Here are a few ways to think about moving fast.
Isaac Newton famously said: “If I have seen further it is by standing on the shoulders of Giants.”
When building a product, don’t be afraid to borrow from solutions that already work. Steal what you can with pride. Look for existing patterns and use them. Don’t waste time re-inventing the wheel, especially not in areas that aren’t key to your differentiation.
As Picasso said: “Good artists copy, great artists steal”.
Every project has constraints. For an artist that might be the size of the canvas. For a technology product it might be the business model or the underlying technology.
But not all constraints are equal. Some are very hard, and others are flexible.
Look at the constraints you have and ask: which ones are flexible? Which are not even constraints at all?
Can you simplify the task by challenging one of the constraints?
Alfred Einstein said (approximately): “Everything should be made as simple as possible, but no simpler.”
Complexity is the silent killer of products. Complexity is a poison that spreads lethargy and chaos in your startup. The more complex your product, the harder it becomes to maintain. Avoid complexity at all costs.
Always start by doing the simplest thing first. Ask this key question: What is the smallest, simplest thing we can do that will validate our hypothesis and deliver value to our customers?
I’ve seen people (and whole teams) bang their head against a hard problem for days, or weeks, without asking for help. Sometimes it’s a mix of stoic determination and pride; sometimes it’s that feeling of being ever-so-close to cracking the problem… for days and days on end.
Productive people know how to ask for help early. Whatever the issue is that you’re facing, the chances are there are people out there who can help you. Sometimes a point in the right direction is all you need to unblock yourself and save hours or days of wasteful wheel spinning.
First and foremost, use your colleagues. Don’t be afraid to ask more experienced team members for help early on. It’s not your job to know all the answers; it’s your job to find the answers. There is no shame in asking for help! It’s how great people learn.
Second, build your network outside of your team. This could be in your company, or outside it. Find the networks, groups or meetups in your area of expertise, and use them.
If you have any questions or would like some more detailed tips, get in touch!
From The Verge:
Twitter has made follower counts appear less prominent on its iOS app by making the font size smaller in a new redesign effort, according to a Twitter spokesperson. The change comes after CEO Jack Dorsey repeatedly said that he wants to rethink how the company could prioritize “meaningful” conversations over numbers like retweets, likes, and follows.
I would absolutely love to know how much design time, discussions, debates, arguments and philosophy went into making this change.
Positioning this as a “de-emphasis” in any meaningful way seems quite a stretch to me.
The attention on followers and volume of attention is the product of a decade of social media’s push on attention, clicks, scrolls and feeds. We’ve been conditioned by years of Twitter, Facebook, LinkedIn, Instagram etc to value audience size over quality of conversation.
Wanting to change this is admirable, but it’s going to take more than font sizes. It will mean changing the incentive structures of the products in ways that might hurt growth in the short-term… and that’s still going to be a tough row to hoe for these companies conditioned on growth at all costs.
When we look around and see the absolute domination of companies like Amazon, Apple, Google and Facebook, it’s easy to assume that the technology boom is over, and that these companies took all the profits.
But a16z’s Benedict Evans has a different take: he argues that tech is only just getting started.
He calls it “the end of the beginning”… the “beginning” being connecting every person on earth to the internet.
In the next phase, we have a new set of decentralised building blocks – such as machine learning and the blockchain – to power a new wave of tech innovations that could target the trillions dollars worth of market share still not captured by the tech industry.
Health care, housing, finance, retail and more… not to mention politics or social welfare.
Watch his presentation from the annual a16z tech conference, which he originally posted on his blog here.
I just finished reading The Circle, the dystopian view of a world when the next Facebook completely abolishes privacy once and for all. The scariest thing about the book is how real – how possible – it all seems. The world is a few decisions away from being set on that path.
I read today in The Guardian that companies are starting to microchip employees for real:
The tiny chips, implanted in the flesh between the thumb and forefinger, are similar to those for pets. They enable people to open their front door, access their office or start their car with a wave of their hand, and can also store medical data.
It’s super scary. It’s a precedent that leads to a scary future.
Marty Cagan was in Berlin recently and did a talk about why teams are not truly empowered, and what teams might do about that.
1. The team is staffed with competent people with the necessary range of skills.
2. The team is assigned problems to solve, and they are able to decide the best way to solve those problems.
3. The team is accountable for solving the customer or business problem (outcome).
This is a powerful lens to use to look at a team – either one that you’re managing, or one that you’re a part of – and assess the level of true empowerment.
The framework also fits well with the general idea of using OKRs (Objectives and Key Results) as a tool for managing autonomous teams:
1. The team is staffed with competent people with the necessary range of skills (the pre-requisite for any team to be productive and impactful).
2. The team is assigned problems to solve (ie, OBJECTIVES), and they are able to decide the best way to solve those problems.
3. The team is accountable for solving the problem – which you measure with metrics or other measurable outcomes/KPIs (ie, KEY RESULTS).
Basically this is a recipe for using OKRs to drive empowered teams:
Objective = problem to solve
Accountability = measurable outcome
You can use this framework while evaluating the teams in your company. It could also be used as a tool in a retrospective: the team can each provide a rating, say out of ten, to the extent that they feel they are empowered, measuring each of these three trajectories, and you can track this self-evaluation over time to monitor the trend.
You can watch a recording of the talk here.