Category: Blog

I like to know what’s going on with people I respect, what they’re thinking about, and stuff they’ve learned. But social media is an unreliable way of finding what they’ve written recently. The algorithms make it impossible to know what you’ve missed. So, I wanted to create a reliable, timely and free way of finding out what these people have published.

Lots of personal website and blogging platforms, along with sites like YouTube have RSS feeds, which is a great way to get links to newly published content. Unfortunately, not all do, so I guess there’s still some people’s writing that I’ll miss. No solution is perfect.

I looked at using automation products like Zapier and IFTTT, but there are two drawbacks. The free plans allow a very small number of feeds, and until I’ve proved the value for myself I don’t want to spend too much on this. And I’d still need somewhere else to display the feeds that could notify me and organise the feeds, and as I’m still validating whether the idea works I want to keep the system as simple as possible. It’s good to know your constraints.

Slack, as it turns out, is a great solution. It has an RSS app that can post into channels, different channels let you organise messages, and message features help you

My workspace

I set up a workspace just for myself, and created channels for ‘product management’, ‘agile’, ‘ai’, design’, strategy’ and ‘weeknotes’. As my interests change, I can add and remove channels without disrupting the whole solution. And if there’s someone who’s writing doesn’t fit a single topic, I add their feed to the ‘general’ channel.

Slack has other features that help with the content discovery experience too. Messages can be bookmarked or have a reminder set for later. I also use different emoji’s to help me. A tick means I’ve read the blog post. Thumbs up means I really liked it and might want to come back to it later.

Slack is one of the few apps that I enable notifications on my phone, but it means I’ve got belt and braces for not missing new content. I get a notification when someone posts a new article or video, and if I’m too busy to read it then, I’ve got unread messages next time I go into the Slack app so I can read them then.

Improvements

What could be better? The main thing would be a way to tidy/select the contents of RSS message before it’s posted. Substack is one of the cleanest, but there’s still messy duplication. Ideally, I’d see just the name of the publication and the title of the article which links to it. That would mean less unhelpful, unfinished text and less scrolling.

My feeds list

Feed	Channel
adrianhoward.com	agile
Alan Wright	productmanagement
All Things Product Management	productmanagement
Andy Bell	design
Artefacts	strategy
Ben’s Bites	ai
Charles Lambdin	productmanagement
Continuous Delivery	agile
Dan Olsen	productmanagement
Dave Briggs	gov
Edo van Royen	productmanagement
Emily Webber	agile
gilest.org	agile
Harsh Browns	productmanagement
https://hitenism.com/feed/	productmanagement
Matt Edgar writes here	weeknotes
One Useful Thing	ai
Product Coalition – Medium	productmanagement
Product Growth	productmanagement
Product Management IRL	productmanagement
Scott Colfer’s Blog	productmanagement
Sid’s Product Newsletter	productmanagement
Stories by Alysia-Marie Annett on Medium	design
Stories by Andy Tabberer on Medium	agile
Stories by Conrad Meagher on Medium	design
Stories by Holly Davis on Medium	weeknotes
Stories by Joe Roberson on Medium	design
Stories by Laura Heatherley on Medium	weeknotes
Stories by Lauren Pope on Medium	design
Stories by Neil Killick on Medium	agile
Stories by Zach Moss on Medium	weeknotes
Teal Unicorn	agile
Terence Eden’s Blog	general
The Beautiful Mess	productmanagement
The Civic AI Observatory	ai
The Product Experience	productmanagement
The Product Science Podcast	productmanagement
Third Sector Lab	charity
UX Collective – Medium	design
Web of Weeknotes – Medium	weeknotes
Roger Martin on Medium	strategy

I’ll keep adding to this list as I add more feeds to my Slack.

What’s next

I’d like to find a way to decouple ‘conversation’ from social media. I don’t converse a lot on social media or any other platforms, but I’d like to know that I have a reliable way of doing so if I wanted to.

It would be great if social media platforms introduced RSS feeds so, for example, if someone posts on LinkedIn or Threads I could add replies, but I don’t think that will ever happen. And other platforms like Substack and Medium aren’t well designed for conversation. Another problem for another day.

Roadmaps are best created using deductive reasoning, starting with the end in mind, and with the outcomes and opportunities for achieving them. There’s lots written about outcome-based roadmaps and how to create good ones.

But, often, instead of outcome-based roadmaps, which as good as are for product managers require a certain amount of familiarity to make sense of, many organisations have feature-based roadmaps or project delivery plans that are called roadmaps.

Of course, product managers can help others to understand the benefits of outcome-based roadmap but that might take some time.

But maybe there’s another way.

Maybe there’s a way to take the outputs expressed in those plans and translate them into outcomes.

Starting with outputs

Let’s start with a website, like the one you’re on now. And a random list of changes that I could do:

• Add a chatbot trained on all the content on the website.
• Redesign the home page.
• Change the menu, e.g., include weeknotes and resources.
• Add a wiki on a subdomain.
• Reorganise the Projects section.
• Write more blog posts.

These are all outputs. Not an outcome in sight. And no prioritisation either. This could be any website, any product or project. So, what’s a product manager to do?

To get to outcomes, we need to group them by what they seem like they are trying to achieve. As we’ve said, if we were starting with what we know we want to achieve, we’d be creating an outcomes-based roadmap, but instead we need to make some assumptions about those outputs which we can test later.

Assuming outcomes

It seems to me that most of the things on that list are about organising stuff on the website; changing the menu, reorganising content, providing a different way of interacting with info on the site. So, we’ll want an outcome that includes all of those. The one that doesn’t quite fit is writing blog posts. That isn’t about organising stuff. Maybe it’s about getting people to the website.

Now, as we’re talking about outcomes, we’re talking about changing user behaviour, so let’s express our outcomes as:

• Get more people to visit the website.
• Make it easier for people to find information on the website.

Then I can group the outputs together by which outcome they seem most likely to achieve.

Outcomes	Outputs
Get more people to visit the website.	Write more blog posts.
Make it easier for people to find information on the website	Add a chatbot trained on all the content on the website. Redesign the home page. Change the menu, e.g., include weeknotes and resources. Reorganise the Projects section. Add a wiki on a subdomain.

Testing assumptions

So, we’ve taken a list of random ideas, made some assumptions about what those things are trying to achieve and grouped them, and phrased an outcome for them. Now we’re ready to test our assumptions. This is important. The difference between a guess and an assumption is that assumptions are called out and tested to try to figure out if they are true. Guesses aren’t, they stay as guesses. Product managers, in their attempts to bring order to chaos and empirical rigor to the messy real world, test their assumptions.

We can ask the people that contributed to the list of outputs whether they agree that those outcomes are really what they are trying to achieve. If they say yes, then our assumptions are validated and hopefully we’ve been able to have a helpful conversation about outcomes. If not, perhaps those people can help create new assumptions about what to achieve and how to group them, and we still get to talk about outcomes.

Prioritising outcomes

You’ll notice that one of our outcome has only one output, and the other has lots (almost like I planned it). So, to get more people to visit the website we can get on with writing more blog posts, that’s obvious. But to make it easier for people to find information on the website, there are lots of thongs that we could do, so we need to choose between them.

Ideally, we’d be able to work on both outcomes at the same time, but if we have to choose between them then we should choose by which provides the most value to the user. In this case, that’s probably writing more blog posts to get more people to the website. How do we know this? Analytics are a product manager’s best friend, and our analytics tell us that the majority of traffic comes from search engines and goes directly to blog posts. Therefore, more blog posts helps more people get to the website.

We also know that the average page view is 1.3, which tells us people aren’t navigating around the site, which back-ups the need for the second outcome and gives us a measure.

Measuring outcomes

For a product manager, just delivering those outputs isn’t enough. That’s fine for project managers but product managers need to know if those outputs are achieving the outcomes.

Measuring whether writing more blog posts correlates with getting more people to visit the website (the outcome) is a far more useful indictor of success than just how many blog posts were written (the output).

This is where we get to the ‘but why’ of outcomes. If one output doesn’t achieve the outcome, then maybe the next one will. The outcome is still worth pursuing because it is closely tied to value. If writing more blog posts doesn’t achieve the outcome of getting more people to the website, we can think of other things that might. Maybe posting on social media or starting a newsletter. Outcomes are more long-standing, and open to new opportunities of outputs being added over time to try to achieve it.

More outputs

If, tomorrow, someone comes up with another great idea, it can be tested against the existing outcomes to see where it fits. If the output they suggest doesn’t help to achieve the current outcomes, then it’s a far easier conversation to explain why it shouldn’t be worked on. And if it doesn’t fit, then we’ve made it easier for people to bring ideas without having to do the product thinking of starting with outcomes.

Product management is a discipline. It is responsible for the entire lifecycle of a product.

Product development is the process of creating a new product. It is one part of the product lifecycle.

Product managers might be responsible for developing a new product but most manage existing products where the goals are to introduce and grow the product as quickly as possible and then maintain the product in the maturity phase for as long as possible.

Developing new products and managing existing products require very different approaches.

New product development

For new product development, validating the riskiest assumptions first is the surest way to create a product that is valuable, usable, feasible and viable.

The riskiest assumptions are about things you know will be important for the success of the product, but which you know little about if/how that thing is going to work in practice. Michael Birchall talks about mapping these things on a two-by-two grid by importance and uncertainty. This is a useful approach as it helps to prioritise the assumptions that should be validated first.

For example, getting the target audience to find out about and try the product is a riskiest assumption that needs validating early because there is no point doing any more development work on a product unless people will use it. This assumption is often validated with an experiment involving a simple landing page with a waiting list and promotional activities to drive people to the page. If no one signs up, the conclusion could be that the value proposition didn’t communicate the product’s value, in which case it can be changed and the experiment run again. But if multiple experiments fail to get people interested, then the assumption is proved wrong and no time has been wasted building a product that would fail.

Existing product improvement

For existing product improvement, removing biggest barriers first will have the greatest effect on the success of the product.

This approach comes from the theory of constraints which says that “Every system has a limiting factor or constraint. Focusing improvement efforts to better utilize this constraint is normally the fastest and most effective way to improve profitability.” There are probably lots of constraints, or barriers, getting in the way of the product being success but only one of them is the biggest. Removing that will have the most positive impact. Then the second biggest barrier becomes the biggest so that’s next to be removed. Eventually, removing barriers provides only marginal gains and this is pretty good signal to stop investing in improvements.

For example, if lots of people are dropping off at the sign-up and onboarding stage, that that is the biggest barrier to users getting value from the product. Fixing that problem will make the product more successful than adding new features for the users that do make it through onboarding (assuming of course that increasing the number of users is the goal).

I think I can explain agile in three words; “uncovering better ways”.

These three words feature in the first sentence of the manifesto for agile software development. They are that important. They tell us the essence of agile.

Uncovering – Finding out as we go, not thinking we can know it all upfront.

Better – Always looking for improvements.

Ways – Tells us it’s a practice, it needs to be done, repeatedly, to make it work.

Good digital teams:

1. stay close to users
2. include different expertise and experience
3. use and understand data
4. create feedback loops
5. organise around problems
6. engage with the world around them
7. embrace flexible technology
8. build in adaptability

Based on Laura Bunt‘s post on leading charities in a digital society.

I’m going to try out some different retro formats, and this month it’s the starfish.

Keep Doing

Tackling the four big risks (valuable, usable, viable, feasible) to create a quality product environment. Last month I started to work on improving how we test throughout the product development process, and on infrastructure reliability. Lots more to do here but stable tech and usable products feel like the most urgent.

I’ll keep working on my side projects:

• The technology charity
• Product management zone
• System-shifting product management
• Responsible product management

My reflective practice of daynotes, weeknotes and monthly retros and delivery planning continues. It’s the most consistent thing I do. I also reorganised my roadmap a bit to make it clearer which items are achieving which goals.

Less Of

Starting new things. Both at work and for side-projects (the list is growing again). High WIP is a constant theme for both. I think I managed to highlight one of the ways that unplanned work arises and gets in the way of planned work.

More of

Systems thinking and mapping for understanding what makes things work the way they do (mostly human behaviour, assumptions, cultural practices, all the kinds of things I find hard to understand).

Using mini roadmaps/kanbans for each project to break the work down into more achievable chunks. I have these in my head but it would be better to have them documented.

Stop Doing

Holding on tightly to things that matter to me but don’t matter to anyone else, e.g., what I see as the corruption of good practice. It’s just not worth the stress of trying to communicate why it should matter to others. I know it’s part of a bigger problem (systems mapping above) but I can’t change it by being dogmatic.

Start Doing

Thinking through side-projects rather than jumping into creating something just because it interests me. Basically, be my own product manager. But still giving myself the freedom to follow my interests. I think I can create some kind of template for this.

I’d also like to see if I can connect my side-projects and thinking more coherently. It makes sense to me that the stuff about responsible product management is one of the practical aspects of system-shifting product management’s vision stuff. And the technology charity is an example of system-shifting product management and using technology to achieve social impact at scale. So, I think they do connect, but maybe not in a very obvious way.

Finding opportunities to connect with people (in and outside the team). I don’t know how yet, but it feels like a valuable thing to do. My usual thinking is that this needs a ‘vehicle’, a reason to spend time together and talk about things but maybe that’s not always the case.

Whatever transformation initiative or framework adoption it is, if it fails, it gets the blame. Agile, lean, OKRs, etc.

But a concept can’t fail, just as it can’t succeed. It’s just a concept. It doesn’t come with inherent success criteria that define success or failure.

An idea, mindset, framework, etc., can’t succeed or fail. Only our implementation of them can, but that’s hard to admit so we blame the thing instead.

There doesn’t seem to anything in the project management principles that a product manager would say wasn’t also appropriate to product management. Maybe they aren’t so different.