Due to “reasons”, taking my temperature every morning has become commonplace. I’ve worked out a Siri Shortcut to log the temperature, check the data and alert me to changes. If you’re interested, and have an iPhone (the shortcut relies on the Health app, so I don’t think it will work on iPad), you can download the shortcut here:
Important: Because the shortcut reads from the Health app, and because that’s protected personal data, you need to run this shortcut on an unlocked phone or it just… silently fails (bad form, Apple).
The Shortcut runs the following actions:
“Hey Siri, log my temperature”
“What is it?” N.B. The answer is expected to be a number
Get my Body Temperature from yesterday, and store it to use in later checks
Log my answer from today as a Body Temperature data point
Check the difference from yesterday, and tell me what the difference is if it’s +/- 1.5ºC N.B. This calculation will work with Fahrenheit, but you might want to change from 1.5 to whatever suits the Fahrenheight scale
If the difference check above passes, simply speak the temperature
Let me know any enhancements, I’m happy to collaborate :)
P.S. I wish it was possible to export a Siri Shortcut in a kind of scripting format, so you could view it on a webpage… or maybe an oEmbed for Siri Shortcuts? That’d be cool.
I’ve been using a quote in roadmap presentations as a nod to the inevitability of change:
“No plan of operations extends with any certainty beyond the first contact with the main hostile force.”
– Helmuth von Moltke the Elder
Reading the Wikipedia page for Helmuth, I now learn he was the creator of a new method of directing armies in the field. Rather than directing all movements in detail, he relied on setting objectives and allowing subordinates freedom to execute within the general framework of the mission. This seems very close to the metrics driven, management by objectives that we see many modern product teams using. Dare I mention OKRs?
Here’s another nice quote, via Marty Cagan’s chapter on Product Objectives in his excellent book “Inspired“:
“Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.”
(N.B. These are notes from my thoughts while people were talking as much as they are notes about what was actually said; I hope I’ve not misrepresented anyone though, and please call me out if I have.)
Nilan Peiris from Transferwise talked about Customer Led Growth, he mentors his teams to constantly remember the problem (fall in love with the problem, not the solution, sounds simple…) and to make big value bets with confidence rather than optimising incrementally (it seems nobody at Transferwise is playing with button colours).
Tom Loosemore’s challenge was around digital transformation in organisations, or “changing the weather” as he put it. Change is challenging, and those pushing for it should remember that this challenge can be emotional, for themselves and for others in the organisation. Tom’s big money slide, much tweeted, was this:
I read this as a message that if you are explicitly choosing or charged to create change in your organisation you are going to ruffle feathers and cause a bit of a stir, to say the least. Tom addressed concerns over the privilege “if you’re not feeling like you’re about to be fired” that this slide has evinced for some:
For me, I found this message of feel the fear and do the right thing anyway inspiring.
A lot of my efforts at the moment are bent to understand and practice product strategy, so I was looking forward Nicholas Goubert’s talk on the subject. From Nicholas I took away that I shouldn’t be afraid of strategy, that “an imperfect strategy is better than none”, and that, as with almost everything, iteration was the key.
Product Strategy is cross-functional, so we need to work with other stakeholders to ensure that everyone is aligned and in sync. Product Strategy needs to be understood by everyone, so reiterate, reiterate, reiterate at every opportunity. Overcommunicate the strategy to promote ownership amongst the team. In his interview on Maggie Crowley’s Build podcast, John Cutler talked about being ready to “walk your belief map”, and this strategy of reiterating the strategy reminded me of that: “we’re doing X because we believe it will promote Y, which will get us closer to our organisation vision because Z”.
Nicholas talked a living strategy which was challenged weekly, and which you are not afraid to update, radically if required, every quarter. Vision, on the other hand, is an immutable constant. Happily share your vision externally, but keep your strategy internal and share only with stakeholders (although that may include customers). The Product Roadmaps Relaunched book talks about your roadmap being a prototype of your strategy, which Nicholas’ advice echoes.
Randy Silver reminded me us of this timeless quote:
The day we stop being curious about our customers is the day our competitors start to catch up.
As well as a simple but important differentiation: don’t talk to your customers, listen to your customers. Aim to pick one tough, meaty question, a question which will get at the “why”, ask it, and then keep listening as your customers tell you their stories (from personal experience, this is harder to do than to say).
Randy also gave us a good Product Management description for when your relatives ask what you do:
Roisi Proven talked about closing the Lizard Loop, listening to your the System 1 (fast, instinctive, and emotional) thinking and backing it up with System 2 (slower, more deliberative, more logical) thinking. She recommended taking a baseline to start, considering what biases and anchors you are carrying, for example:
Do I think unfairly about a group?
Am I blindly or overly positive about my work?
How do I think and feel when users “get it wrong”?
Roisi recommends checking in with your lizard (System 1) and your owl (System 2) before coming to a conclusion. Feel the knot in your stomach, or the urge to optimism, and back them up with data before proceeding.
Roisi also reminded us that the world isn’t just nice people, and that when developing products we should always consider:
What’s the worst that could happen? …or, what if this, but baddies?
We took lessons in negotiation from Garry Prior, and at risk of condensing the 20 minute talk that he gave which condensed a three day training course:
Preparation is crucial: always have objectives from the meeting, consider your wish list, think through the trade-offs you’ll accept… and above all consider the other parties’ points of view
Be comfortable arguing: there will come a point where you need to test the assumptions put forwards by all parties, ask questions, clarify, and listen to others
Negotiation must move towards proposal and acceptance: a good format is “if you do that, I will do this”, open realistically and move modestly
Lucie Mclean considered the similarities between a hedge fund manager and a Product Manager. Lucie talked about considering the spread of risk in your product portfolio:
Low risk work: optimisation, very specific hypotheses, lots of available data… but not an optimal strategy in and of itself
Medium risk work: originating from internal and external signals, “where shall we take this product next?”, no guarantees of success, worth doing an MVP to address the risks
High risk work: Huge hypotheses, “what would we do if?”, big changes and big opportunities, watch out for assumptions and “shiny things lust”
Especially with the high risk strategy, think how much you are betting and consider this as your stake… you might lose it, can you afford to?
5.6 – Make your decisions as expected value calculations. 5.6 a. – Raising the probability of being right is valuable no matter what your probability of being right already is. 5.6 b. – Knowing when not to bet is as important as knowing what bets are probably worth making. 5.6 c. – The best choices are the ones that have more pros than cons, not those that don’t have any cons at all.
In managing your organisation’s portfolio of risk, you can ask “what is our risk appetite?” As well as “what is our expectation for gains?” I’ve found myself referring to these thoughts recently, as I talk through our product portfolio with colleagues at my organisation.
David Wascha closed out the sessions for the day, with an invitation to Look to the Left. When looking for a new product at Travelex, he and his team asked the following questions of different activities consumers conducted: “how important is this to you?” and “how happy are you with it at the moment?” Traditionally Travelex had concentrated on a series of consumer actions which went:
Return (and sell spare currency)
When they talked with their customers they found a step 0, a step to the left of the sequence they were looking at:
0. Plan (how much you need)
The goal with the “look left” technique is to extend your engagement with customers. For example at Moonpig, the team are looking left to prompt and remind customers of upcoming occasions they need to send cards for… but also looking right, to close the loop “would you like to send a free thank you card to the sender of this card?” (this answers the perennial card-senders question “did they get my card”, and possibly the more important question “did they get my card and do they think I’m great for sending it?”
Looking back at my notes I got an enormous amount out of MTPEngage Manchester, and I’m so grateful to be living in a city with such an active and engaging product scene.
Call me out for any misunderstandings or odd assumptions in my notes above in the comments, or tell me about other product conferences I must go to.
You can think of an experience vision as a giant flag on a tall post in the sand, far away on the horizon. The flag is too far way to walk to anytime soon. It will take years. (In the case of the Knowledge Navigator, it was 23 years.)
Yet, because the flag is visible from where we currently are, we can set a directive: March towards the flag. Everyone in our organization can have the same directive. We’re all marching towards the same point of convergence, even if we’re starting someplace different.
Recently Mo Jangda and I wrote “Future Stories of VIP” for each other, as a means of opening up and understanding the personal vision for the future of our work at VIP. We’ve since been posting the stories internally to bring the vision to our wider team for discussion and critique. Reading Jared’s article inspires me to continue writing and refining stories that bring to life the experience of our clients in the future.
You’ll know your experience vision has taken off when other people start explaining it to you, to make sure you’ve heard it.
It’ll really take off when you hear a senior executive, at some organization-wide meeting, use your story to explain where the organization is heading. They’ll be telling the story (probably getting a few details wrong) to everyone, saying “This is where we need to go.”
What happens next is magical. The organization starts to focus less on what the competition is doing. Decision makers ask What baby steps will it take to get closer to our vision?
I listened to Janice explain her UBAD theory as the third tool for uncovering the truth at Mind the Product London, and luckily for us all this talk was videod and is available for your viewing pleasure:
I love it when the streams collide 💥
I’d love to hear from people who’ve used experience visions in their companies, and how they went about creating and utilising them…
The more I think about value the slipperier that word gets, but in a recent conversation something crystallised for me, a little crack in the facade of my naivety. I realised that when you’re serving businesses, value is realised differently for the client organisation than it is for the users in the client organisation. (It seems obvious now I write it down, but I’ll plough on regardless.)
At my organisation, VIP, we provide services around WordPress to Enterprise organisations. We think about “our client” at two levels: the client organisation and the users in the client organisation. The “client organisations” are the entities using our service to move their business forward (for whatever value of “forward” that they… ahem… value). The “client users” are the people up and down the client organisation that are trying to do their work harder, better, stronger, faster to create “value” for their organisation, and some of the time they’re using our services as part of their work.
When I think about the potential value in an opportunity, I’m now also considering whether that value is addressed directly to the client organisation, or is afforded to the client users, as well as the frequency or consistency with which value can be provided.
Consider a feature which your clients use only rarely, for example domain mapping. A domain mapping UI needs to be clean, usable, and validate inputs… but clients are unlikely to be mapping domains frequently, so improvements there need to be huge to provide value to a client.
(Of course this is simplified; while a feature may only be used once in the lifetime of a site, we may still need to prioritise it as a vital part of launching a site or unlocking some scaling challenge.)
Alternatively, consider an opportunity to address an issue or improve a workflow for client developers in the course of day to day development, for example syncing data from production environments to test a bug fix. The value client users experience when we improve data sync will multiply over many uses by many individual users across many client organisations. So while editing DNS is important and needs to be done right, the frequency of use of the data sync feature means the potential value provided is greater… so data sync will provide the greater return from the team’s attention.
There’s another class of opportunity, opportunities that open significant options for a client organisation to realise value, either by making something practicable which was previously out of reach, by reducing costs, by consolidating functionality under a single supplier, etc. An example here might be a hosting platform offering a fully integrated global CDN, meaning clients that significantly value page speed and customer experience no longer need to deal with the integration complexity of a third party CDN or pay for it. The right opportunity here can provide much greater value to our clients.
So, crudely, I’m thinking of three buckets, from good to better to best:
Features which are only used once in the course of a client’s engagement with us, though these features may still need to be prioritised, e.g. if they are part of onboarding or some other vital process.
Opportunities to improve workflows or address issues encountered frequently by client users in the course of their work.
Opportunities which allow the client organisation to increase value, protect value, or reduce or avoid costs.
How am I doing? If you’ve got any thoughts on my thoughts, please add them in the comments here.
A research minded Product Manager, if a competitor just launched a new product, they go out and talk to users right away: “what does this mean for you?”, “how does this fit into your life?” They’re looking for those opportunities to discover new things rather than sitting and saying “we need to get to feature parity with them right now”.
Because customers don’t really care about feature parity, everything is part of an experience, part of a journey, and Product Managers who excel at research are always proactively seeking out that new information, those new challenges and looking for ways to activate that before someone tells them to.
I like this framing of competition research as digging into the problems a competitor is trying to solve, rather than copying their implementation. The deeper thinking suggested here seems likely to turn up ways that your company can improve on the solution, make it your own, or perhaps even determine that this opportunity is not necessary or not a priority for your customers.
Don’t use Lines of Code to measure productivity, you end up with pointless lines of code
Don’t use agile velocity (i.e. story points burn down), these are more a measure of effort for capacity planning purposes (and they can be gamed)
The interviewees (Nicole Forsgren and Jez Humble) recommend:
Lead time (code commit to code deploy) – they talk about this as an “outcome” not an “output”, but I’m not sure I entirely follow here, though I do see it as a measure of the whole team’s ability to deliver value (assuming that’s what the code commit delivers) to a client
Time to restore
Change fail rate
…but Nicole and Jez admit there are gaps here in measuring if the change delivers value (i.e. effectiveness, efficiency, customer satisfaction, delivering mission goals)
I wonder if there’s a “time to positive outcome” metric (using the outcomes defined when the opportunity was identified), which would encourage tight iteration to allow frequent course correction? Measuring a team on the outcomes they themselves define when the opportunity is identified requires a team of high moral fibre, as there’s a possibility to game it right there.
As part of diving into Product Management, I noticed that Marty Cagan of Silicon Valley Product Group was speaking at a Business of Software evening in London. Marty was recommended as a figure to follow by Brie, my colleague at Automattic, so I grabbed a ticket immediately.
Marty centred his talk around unleashing and empowering the engineer, and it was incredibly impressive and inspiring to listen to him. It’s always wonderful when you’re learning from someone with sufficient mastery of their subject that questions always trigger a well thought through response, backed up by multiple examples. Here’s my tl;dr for the evening: