Full loop product management

Full loop product management is an approach and a skillset that allows product managers to be involved throughout the entire lifecycle of an opportunity. It starts with understanding potential opportunities, brings them into the organisation to align with strategy, creates a means of leveraging the opportunity, and takes it out into the world and measures it’s impact.

Full loop applies to any size or stage of organisation and for new products or for improving existing features. It’s a way of joining up the parts of the value stream that creates products, of giving the whole process more coherence, and so creating more valuable products that leverage the right opportunities.

Full loop product management

Full loop

There are four parts to the loop.

External discovery

From horizon-scanning across an industry to competitor analysis to interviewing customers, external discovery is all about finding opportunities for the organisation and the products.

Internal discovery

Internal discovery involves bringing an opportunity into the organisation and aligning it with organisational and product strategy. In some organisations this involves writing business cases and managing a roadmap.

Internal delivery

Building the new product or feature, and especially ensuring the rationale for how it will leverage the opportunity, is part of internal delivery. This can involve working in agile ways with developers and testers, writing user stories, and communicating progress. This is often where product managers spend (too much of) their time.

External delivery

Delivering the solutions for customers to use includes go-to-market planning, marketing and promotion, and customer support. Monitoring the effect the solution has in the external world completes the loop and informs the ongoing external discovery to understand whether the product or feature is leveraging the opportunity.

When product managers are involved in all sections throughout the loop they are more able to reduce the disjointed lack of connection between an opportunity, a solution and its impact. The more connected and coherent the product development process is, the more value it will deliver.

Some anti-patterns

Internal delivery only

Many organisations focus their product managers on only internal delivery, in the bottom right quadrant. Whenever a product manager job description talks about tools like Jira and agile but doesn’t mention understanding customer needs or measuring outcomes, that’s a sign of an organisation that constrains it’s product managers to only doing internal delivery work. This is the source of the criticism of product managers being used as project managers. If they are not involved in understanding the problem or opportunity, and not involved to launching and measuring the effectiveness of the solution, then all they can do is manage the small part of the loop that builds the software.

Internal discovery and delivery only

A organisation that expects its product managers to only work across the internal quadrants, usually means a product manager taking ideas about often unvalidated opportunities from internal stakeholders and liaising with developers to build something that the stakeholder specifies and thinks will deliver some unspecified value. In job descriptions this often shows in phrases such as “liaising with stakeholders”, “communication skills” and “writing requirements”.

External delivery only

It’s rare for a product manager to be only focused on the external delivery of a product, things like go-to-market plans, marketing, customer support and success, but it’s worth being aware of as there’s an emerging trend of product management shifting more towards marketing in some tech firms.

Using full loop product management

So, how do product managers constrained within one part of the loop start to get involved in the other parts? Those other parts of the loop happen within an organisation. They may not happen in a coherent and robust way, but they do happen. Find out where and how, speak to those people and ask to learn about what they do. Get involved. Find ways to make their lives easier. Move upstream and downstream, and connect people and ideas along the way.

Coherence doesn’t happen by accident, and is so easily lost in the handover between teams and across different parts of an organisation. Full loop product management fixes that.

Weeknotes 286

Photo of the week:

Full moon over the south Wales coast. I was a perfectly calm evening.

This week I did:

Continuous improvement

A big focus for me this week has been on building up a process for the continuous improvement of products as the number of products increases without having a big impact on the team’s capacity to work on new products or overwhelming them. It’s been interesting to think about how it requires a different approach, one that it’s based on the deep qualitative user research we do when developing a new product or service, but instead

Ethical product decision-making collection

I wrote up a collection of articles, reports and tools for applying ethical thinking to product decisions at ethicalproduct.info. Over time I’d like to develop it further so it becomes more than just a collection and more useful for product teams to use in their decision-making.

Ethical Product is one of three new products I’ve launched so far this year. I didn’t set out with that as a goal (in fact, quite the opposite, I had intended to work on getting FutureSkills.info live) but I’m going to see if I can do another two by the end of January.


This week was the 75th anniversary of the Doomsday Clock, which was created as a symbolic warning of how close humanity is to destroying itself. Today, the clock is at 100 seconds to midnight, the closest it’s ever been to the end. This fascinates me so much that I made a (currently tongue-in-cheek) website about whether the world has been taken over by AI, which is our most likely technological threat, and wrote about it for the Irregular Ideas newsletter.


This week I reached 250 places visited and I was briefly the most westerly person on mainland Wales. These unique little milestones keep me entertained.

And I read:

How Complex Systems Fail

Richard Cook writes on the nature of failure, and has eighteen principles that help us think about what is going on in complex systems when they fail. He says that even though complex systems develop defenses against failure over time they are often run in a broken state and are close to failure.

I also listened again to the episode of Cautionary Tales that talks about how accidents happen and how we always look for someone to blame rather than designing better systems. Systems are vulnerable to failure when they are tightly coupled and complex, meaning the components interact in unexpected ways. The complexity of the systems means there will be surprises and then tight coupling meas there is no time to deal with the surprise.

Loosely coupled simple systems FTW.

Road Ahead

NCVO’s Road Ahead 2022 report provides an analysis of the biggest trends, opportunities and events that will impact charities and volunteering. It’s interesting to consider such a wide range of factors affecting the charity sector over such a short time period.


This list of Charity APIs is full of possibility. I wonder how much they are used.

I thought about:

Cause-and-effect and Networks

I summed up some of my thinking about how product managers can use two modes of thinking; networks and cause-and-effect to think strategically. In network thinking, tactical deals with the parts and strategic considers the connections between the parts. And in cause-and-effect thinking, tactical deals with things in isolation and strategic connections things in a causal chain of logic.

Systems solutions

I had a really good great chat with another charity sector product manager this week, and we talked about a product they were working on to tackle a pretty complicated problem. It got my thinking about how system-shifting product management approach might solve the problem differently to a user-centred design approach. Whereas a UCD approach starts with the user experiencing the problem and assumes the solution is in acting upon the user to change their behaviour, a system-shifting approach looks to act on the surrounding systems and change them


I had a chat this week about remote working and how different it is getting to know someone only over video versus in real life. It made me think about whether we present ourselves differently virtually, does it make it easier for introverts and those with social anxiety. And it made me think about how I come across online versus ow I see myself in real life. My Big Five scores are Openness to experience: 96 out of 100, Agreeableness: 75 out of 100, Conscientiousness: 96 out of 100, Negative emotionality: 0 out of 100 and Extraversion: 42 out of 100. I wonder what that means.

Weeknotes #281



👋The end

Last week at the Prince’s Trust. It’s been a turbulent two years for the Trust (not because I was there, there were other factors) but I feel like I always managed to maintain my even keel to understand what problems I’m trying to solve, treat all my colleagues with kindness, and help the org learn a little about being a more digital organisation. I received this Kudoboard from some of the people I worked with. It seems like a better testimonial to my impact than delivering any product.


My website has received 25,000 views and it only took six years.

The three most successful posts account for 21.23% of views:

The top ten posts received 9417 views, which is 43.27% of total, and is mostly from organic search traffic as they seem to be about things no one else has written much about.

The top twenty percent of posts account for 85.63% percent of the views.

317 posts have received 10 or fewer views, which accounts for 9.16% of total views.


Started setting up the ENS for rogerswannell.eth. Web3 stuff continues to divide people on Twitter (and the rest of the internet). There are so many perspectives. It’s really interesting to get a glimpse of how people think about things like this and the (usually unbalance) arguments they come up with to defend their position. I’m no expert but it seems that, for example, arguing that the cost of compute power makes web3 a failure when web3 isn’t trying to solve the problem of cost-efficient computing is like criticising candy floss for not being a good building material. Is web3 a scam? Well, yes, just like every other market that uses imaginary value exchange. And the Pareto principle always applies; a few get really rich and most get poorer.

🌍Top 0.000000052% of the population

The Irregular Ideas newsletter had a hundred per cent open rate this week. That’s not that impressive given that I only have four subscribers but I’m glad that after eight issues they are still opening it. Evan Armstrong wrote in the Napkin Math Newsletter, “Nothing about email or subscriptions fixes the problem of building a media company. Namely, it is just really, really hard to make interesting content every week and to get people to pay attention to it… Newsletters are here to stay and the trend won’t go away, but Newsletters will slow down as independent, focused businesses. Instead, expect newsletters to pivot into mutli-media companies because other formats are quicker and easier to create.” It’s a fair point. Newsletters are just a channel for expressing ideas, so firstly you’ve got to have ideas people want to know about and secondly you’ve got to provide them in the way people want to consume them. I’m not convinced that any idea/expression-of-an-idea can work on any channel.

🌈Red and yellow and pink and green

I completed module two of the BSL course covering numbers, colours and organisations. I know I’m still at the basics but I’ve surprised myself with how well I’ve been able to remember the signs.


Futureskills email continue to progress very slowly. I really need to stop coming up with new ideas and get this one to a point where it can launch. I’ll try to make it my main focus over the few weeks remaining of this year.

📖Side-project playbook

I’ve been starting to work on what a playbook for my side-projects might look like. ‘Start with a domain name‘ seems like something that would be part of it. I haven’t always started all of my projects with a domain name but having thought about it, it seems like a good idea. Having a domain name for a project starts to give it an identity and some brand, which is useful however the project pans out. My current projects:


🤼Digital civil society

The beautifully written ‘Digital Civil Society: The Annual Industry Forecast‘ by Lucy Bernholz has some really interesting and forward-looking thoughts about the dramatic changes coming to a society near you very soon. The phrase, “Disruption is something well-resourced, valorized individuals and companies do unto others; discontinuity is done unto all of us.” caught my eye and summed up the wrestling that is going on between governments, corporations, civil society bodies and individuals.

🤷‍♂️Answering the ‘why’ and the ‘how’

Philippa Peasland wrote this brilliant reflection on driving digital transformation by adopting decision stacks. It’s really interesting to get some hint of how the interplay between a simple tool and the complicated organisational dynamics takes place. As Philippa says, it’s the conversations that count. Changes happens in the minds of the people before it happens in the behaviours of the organisation.

📉Effort and reward

Mark Manson talks about how we should “teach [our mind] to stop chasing its own tail. To stop chasing meaning and freedom and happiness because those only serve to move it further away from itself.” The lesson of the piece is thought-provoking enough, but more interesting is the relationship between the three graphs he refers to in describing the three types of tasks we all perform. He says when an “action is mindless and simple effort and reward have a linear relationship. Effort and reward have a diminishing returns relationship when the action is complex. But when the action becomes purely psychological—an experience that exists solely within our own consciousness—the relationship between effort and reward becomes inverted.” These bear more thinking about from a productivity and planning point of view.

Thought about:

🤝Project and Product

Product thinking is different to project thinking. No doubt about it. But that doesn’t mean they need to viewed antagonistically, that for one to be right the other must be wrong. Good things happen when project and product thinking are merged in ways that work for the environment and circumstances. Don’t identify by job titles, the team is the unit of delivery.


The more I think about it the more I’m convinced that timing is the single most important factor for the success of anything. Whether it’s a startup launching a product, a business delivering a project, or an individual trying to achieve anything at all, if you can’t answer the question, “why now?” then you’re just guessing. Validation efforts, then, shouldn’t just be about the idea, they should be about answering that “why now” question. Being too late, too early or on time is far far harder to understand, which is probably why we don’t really try to.

👩‍🏭Work mashup

Good work provides choice. Office/hybrid/remote or synchronous/asynchronous, work should work for everyone. We should be figuring out how to create bridges between these things rather than arguing about which one will win. One small attempt I’m interested in using more is meeting notes. I think, done well, meeting notes can bridge between synchronous meetings and asynchronous work after the meeting. I just need to figure out what good meetings look like.

💻Working for the algorithm

This tweet by Aprilynne Alter got me thinking about the myth of how different solopreneur/indie hacker/creator work is to being employed by an organisation. I think they are more similar than they are different. The suggestion that this way of working builds a future of passive income doesn’t stack up. If you don’t keep producing then income will reduce over time. And scaling of income and progression prospects work the same whether you’re working for an organisation or the algorithm; the few get to the top and make lots of money whilst the majority are poorly paid. Some of the comments in Aprilynne’s tweet talk about producing more content based on what previously performed well, which is the same as being employed and . The same mechanisms apply to work whether you’re working for an organisation or working for the algorithm, don’t convince yourself otherwise.

The reasoning behind the roadmap

There’s more to creating a product roadmap than putting boxes on a diagram. To create effective roadmaps you need to understand the logic that applies behind the boxes.

Product roadmapping uses deductive reasoning. It starts with a theory, sets a hypothesis, and then makes observations to prove or disprove the hypothesis, and so deduce conclusions from things proposed by the theory.

Products start with the ‘subjective theory of value‘. It states that value is determined by the importance an individual places on a good for the achievement of desired ends.

When we talk about products meeting user needs or outcomes, we’re talking about the subjective theory of value. It says users value meeting their needs more than they value the money the product costs, that’s why they pay.

Next we set hypotheses to test the theory. It could be ‘releasing new feature X will meet user need Y and users will pay Z for it’. We might show this on a roadmap as ‘Feature X’ but really we’re expressing the hypothesis.

When we measure how well that feature is performing we are conducting observations to prove or disprove the hypothesis. If we get feedback that the feature is meeting the need and that users are willing to pay for it, then we’ve proved our hypothesis correct.

We use deductive reasoning for roadmapping because it closely follows the path of logic and has advantages:

  1. Explains causal relationships between concepts and variables.
  2. Measures concepts quantitatively.
  3. Generalises findings to a certain extent.

Concepts are abstract ideas like ‘paying’ and a variable might be ‘price’. Deductive reasoning helps us understand the relationship between the price, which we can change, and the how likely users are to pay that price.

We can measure a concept like ‘paying’ quantitatively by observing how many users pay and how much they pay. This helps us understand the concept more objectively and build theory off of it.

Deductive approaches allow “reasoning from the general to the particular” (Pelissier, 2008) meaning that what we can link premises in the theory with conclusions from our observations.

So, roadmaps are more than just a diagram of features, they are a means to bring the discipline of deductive reasoning to product management and to express the hypotheses that we use to test theories.

Charity Service/Product Model Canvas – iteration 2

Charity Service Model Canvas – iteration 2

Users at the centre.

Understanding needs and problems on one side and outcomes on the other.

Acquisition and Solutions intersect the Users to show that equal consideration needs to be given to getting people using the product as building it.

Below the line of user interaction is Costs, Partners, Resources and Funding.

Doesn’t have Activities like iteration 1 did. Should it?

Weeknotes #278

Photo of the week:

Season’s greetings, by Banksy, ironically displayed within a shop.

On this week’s Done list:

Connecting concepts in systems

I’ve been working a lot this week on how different systems ‘conceptualise’ things and how those concepts move between systems with very different data structures as the data moves between them. The same ‘concept’ is defined in different ways and needs translation and common language between the systems. What constitutes the identity of a user in one system isn’t the same as in another, but it’s easy to miss the impact of the differences if you don’t dig into them.

Irregular Ideas

Sent out the thirteenth, fourteenth and fifteenth irregular ideas. I feel like my writing is getting a bit better with the constraints of talking about a specific idea, only having a few paragraphs to do so, and putting it in an email so I can’t change it later. It’s different to writing a blog post where I’m more likely to throw in lots of loosely connected things.

Future Skills

I worked on the first email for the Future Skills guided learning to try get the template right which will hopefully make writing the other nineteen emails quicker. I need to give it lots more time and get the emails written and set up so I can start marketing it. Of all my side-projects it feels like the one that has the most potential for actually meeting a need rather than just being of interest to me. I think it might still not be practical enough but until I get some people using it and get some feedback it’s all guesswork.

Systems-shifting product management

I set up a project page on my website and started to try to define systems-shifting product management, including the idea that product managers develop by learning how to increase their leverage rather than gaining influence and authority within the organisational hierarchy.

Stuff I read and listened to this week:

Public service product management

I listened to Tom Loosemore on ‘the product experience’ podcast talking about product management in the UK government. He talks about how part of product management is creating that space in organisations to do product management, that understanding user needs is do much harder then we think, especially in environments with messy and uncertain human behaviours and that joining up teams, channels, and solutions is essential for achieving the real outcomes for people.

Using maps

Simon Wilson, also on ‘the product experience’, talked about using mapping to know where we are and where we’re going. Mapping, and working in visual ways, are useful for bringing the users of a service forward into people’s thoughts. Maps help us understand the shape and scope of a problem, who it affects, how it affects the organisation. They show us a narrative and help us understand movement.

Decentralise decision-making

I read Jason Yip’s post about using doctrine to allow safe decentralised decision-making by establishing consistent decision logic. He writes/quotes, “Strategy doesn’t give employees enough guidance to know how to take action, and plans are too rigid to adapt to changing circumstances. In rapidly changing environments, you need doctrine to get closer to the ground. Doctrine creates the common framework of understanding inside of which individuals can make rapid decisions that are right for their circumstances… If strategy defines objectives, and plans prescribe behavior, then doctrine guides decisions.” Jason proposes an Agile doctrine:

  1. Reduce the distance between problems and problem-solvers
  2. Validate every step
  3. Take smaller steps
  4. Clean up as you go

There’s nothing much to disagree with, either the idea of a doctrine or the things Jason includes within the Agile doctrine. And I completely agree with the problem he’s trying to solve, how to bridge the gap between strategy and plans in a way that fits with modern good practice for cross-functional autonomous teams. The challenge, as always with these things, is the broad context they have to be conceived for and the narrowing of the context for them to be applied.

Three tech trends charities should know about

It’s great to see the emerging tech trends of metaverse and NFTs being talked about more within the charity sector. It’s always hard to start because the typical response is often cynicism and disdain (even from people who you’d expect to want to consider new technologies with an open mind) but given the increasing speed of change it’s even more important that charities do start to understand new tech. Broadly, I think there are three areas of impact new tech might have on a charity that bare some thinking about. The first is how it might affect the people that a charity is trying to help, e.g., gambling charities should definitely be keeping up with how metaverse games will affect gambling behaviour. The second is how new tech might affect the charities existing ways of doing things, e.g. social media fundraising, which to many fundraisers probably looks like just another channel. And then thirdly, how the new tech might disrupt charity business models, e.g., Decentralised Autonomous Organisations forming the basis for a new way of tackling a cause.

Thought about this week:

The discipline

Following on from product managers product managing product management, I’ve been thinking about the discipline of product management. I guess I use the term ‘discipline’ to mean a structure practice, almost like a martial art where the same moves are learned through repetition which means the practitioner can then put those moves together into sequences that work with each other and not against. This discipline and practice, if adopted, accepted, appreciated by an organisation, brings a balance of order and flexibility to how an organisation makes decisions about the products it develops and runs. It brings clarity to what’s important, and uses that to set focus. Perhaps one of the benefits of this discipline is making it easier to see when something breaks from the discipline and disrupts that clarity and focus.

Which way to work

My current side-projects include Systems-shifting Product Management, Irregular Ideas, Future Skills, and future.charity. Along with also doing online courses and writing blog posts (such as weeknotes), I feel like I’m not really making progress quickly enough on any of them so I’ve been trying to figure out the best way to work. I’ve scheduled time for each project one day a week to try to make progress on all of them at the same time, but I still continue to question whether it’s better to choose one project and set myself a bigger chunk of work to do over a few weeks before moving onto another. Before this scheduled approach I just picked whichever project I felt like working on that day, which gave me more flexibility to do easy work when my mind needed a rest and more complicated work when I was looking for more challenge, but lacked structure to get me to actually work on things I might not really want to.

My growth area for this week

Letting go

Definitely letting go. Still a challenge, probably always a challenge, but an important lesson to learn.

Dream team: twelve domains of knowledge for modern product teams

Gone are the days of the product team triad of product, design and engineering. Today’s product teams require skills and knowledge across twelve domains of knowledge.

  • Analysis – depending on the context might be business analysis or data analysis and reporting.
  • Architecture – Tech stack and architectural design and decisions.
  • Content – designing and creating content for product and marketing.
  • Customer success – supporting users to make best use of the product, collecting feedback.
  • Delivery – support development/engineering, remove barriers, schedule and facilitate software development.
  • Development/engineering – Developing and managing software packages for websites and applications.
  • Interaction design – Generate interaction concepts that enable seamless and relevant experiences for users.
  • Marketing- Identify target audience, promote products and services.
  • Product – Align product vision and strategy to organisational goals, user needs, technical capabilities.
  • Project – Manages scope, schedule, finance, risk, quality and resources.
  • Research – plan, design and carry out user and market research activities to get a deep understanding of the users.
  • Service design – Design the end-to-end journey of a service to help users complete their goal

A Leverage Points Framework for Systems-shifting product management

Systems-shifting product management builds on the work of systems-shifting design which moves away from user centred practices in order to affect change by effecting systems.

How might product management use a Leverage Points Framework

Based on the Center for Humane Technology’s Leverage Points Framework, which is based on Donella Meadows ‘12 Leverage Points to Intervene in a System‘, here is version 0.1 of the Systems-shifting product management Leverage Points Framework.

A Leverage Points Framework for Systems-shifting product management

The core concept of a leverage framework is to illustrate that there are multiple points at which leverage can be applied to achieve an outcome, that depending on where on the lever the leverage point is the more or less effect it will have on the outcome, and that multiple leverage points can be used together to increase achieving the outcome.

1 – User action. Leverage applied here is about providing the means for a user to perform an action.

2 – Feature. Leverage at this point involves change to existing or new features in an attempt to achieve the outcome.

3 – Product. Product-wide changes or new products utilise leverage at this level.

4 – Business model. Changing business models applies leverage at this point on the lever.

5 – Organisation. Changes within an organisation can have high leverage on outcomes.

6 – Culture. Changing the culture has the highest leverage in achieving an outcome.

What might that look like in practice?

Example: Let’s saying we’re looking for ways to reduce misinformation on Twitter.

The lowest leverage change that could be made would be to introduce something that relies on a user action for achieving the outcome. That could be something like displaying a message asking the user if they want to read an article before they retweet it. Low leverage changes are quick to introduce but find it extremely difficult to achieve the outcome alone.

The second point on the framework is to introduce a feature that aims to achieve the outcome. This is higher leverage than point one as it is always available for all users and doesn’t rely on a user action. For our example this could be changing the algorithm to reduce the reach of retweets with links so that fewer people then click on and read the article.

Point three is at the product level. This means either wholesale changes to an existing product or a new product. For the purposes of this example lets imagine a very different Twitter where the algorithm tries to keep users in bubbles, reduces the number tweets in users’ timeline that are counter to views they’ve shared, or anonymises content to expose users to different perspectives but prevents the originator from being attacked for expressing them.

Point four is about how changing the business model can achieve the outcome. Twitter relies on driving user engagement in order to create ad spend in order to generate revenue. If social media sites over a certain size were considered a public good and part of the essential infrastructure of countries there could be an argument for governments contributing to revenue in return for Twitter reducing the need for increasing user engagement with certain types of content.

Five is leverage at the organisational level and could include changes to the company structure, incentives that drive behaviours, success measures, the diversity of people working there, how inclusive open to different points-of-view the corporate culture is.

The sixth and highest level point of leverage is to change the culture. This means changing what society considers acceptable behaviour, legislating against certain organisations and public figures to prevent misinformation, or putting memes to work against misinformation.

Or a simpler example: increase revenue.

  1. Send a user more emails, so they click more links, and buy more stuff.
  2. Introduce a feature that users pay more for.
  3. Introduce a product that solves a different problem, and which users pay for.
  4. Change the business model. Move upstream in the value chain, e.g. from buying something from another business to producing that thing that other businesses buy from you.
  5. Restructure the organisation to downsize departments with higher costs.
  6. Change the culture, create a trend so that more people desire what you produce.

Why do product managers struggle to achieve outcomes?

Because they almost always work at the lower levels of the lever. Why do product managers work at the lower levels? Because organisations often really don’t want to change in order to achieve outcomes, especially if they feel they are succeeding with their current features, products, business models, organisational structures and cultural view of the world.

Not only is is hard to do, it’s also difficult to be sure you’ll achieve the desired outcome. Any action in a complex system will have unintended consequences, but higher leverage changes are more likely to have vastly disconnected consequences which are impossible to tie back to the change.

Once it’s on the internet you can’t get it back

I had a slightly surreal phone call. It was from someone inquiring about something I’d been involved a few years ago. After the call I wondered about how they found my number. A quick Google search and I found lots of websites had my phone number. In promoting the thing I’d been working on I had added my phone to a website. Lots of other websites scraped that website and so it’s data became their data.

A product manager, or someone assuming the responsibilities of a product manager, made choices about how those websites were going to work. They considered ‘their user’ as the person visiting their website and wanted to provide a wide range of information. They assumed that data on the public web is free for all to use. And they probably didn’t spend a great deal of time thinking about the original owner of the data, how they should have some control over how that data is used, and what problematic or harmful things could result from it being used in ways they didn’t intend.

Today, product managers working with public data sets or building products that allow users to share information about themselves publicly have no excuse for not considering the wider impacts of their choices. It’s irresponsible to assume that because data is open for all to see that this means it’s free for all to use. It’s irresponsible to push the responsibility for making those choices onto users and not inform them of the risks or give them the tools to manage the data they share.

Luckily for me, the thing I was working on was very niche so I don’t expect much interest and I’m pretty good at ignoring phone calls, but it made me think about how once we’ve added something to the internet we lose control over where it goes and how it’s used.

Everything is connected – Design accordingly

We should design products based on what systems they interact with, rather than how they change user’s behaviour.

Every product connects to and interacts with other systems. And when we realise that everything in the world is connected in some way or another, we begin to be able to see how the products we design and build can play a part in changing systems.

“In an unstable complex system, small islands of coherence have the potential to change the whole system.”

– Ilya Progogine.

Rather than producing products that distract, nudge, isolate, we can produce products that intersect meaningfully with other systems to create those islands of coherence.