[{"content":"Write the post in Markdown.\nA heading A paragraph with a link.\n","permalink":"https://alaniswright.com/blog/migrating-from-wordpress-to-hugo/","summary":"\u003cp\u003eWrite the post in Markdown.\u003c/p\u003e\n\u003ch2 id=\"a-heading\"\u003eA heading\u003c/h2\u003e\n\u003cp\u003eA paragraph with a \u003ca href=\"https://example.com\"\u003elink\u003c/a\u003e.\u003c/p\u003e","title":"Migrating from Wordpress to Hugo (with a little help from Cursor)"},{"content":" Six months ago I started an MSc in Artificial Intelligence at the University of Bath. Six months before that, I began a crash course in Python and mathematics. This blog post covers the best free resources that I found most helpful. If you are preparing for a degree in AI or computer science and you are from a non-technical background, this post is for you. My background My undergraduate degree was a BA in a non-STEM subject (Economics, Politics and International Studies \u0026#8211; not quite PPE but nobody knows what EPAIS stands for). I have been working as a product/program manager in tech for more than 15 years, but have had limited exposure to mathematics and programming, either academically or professionally. Python preparation: University of Helsinki The Python Programming MOOC from the University of Helsinki is the best resource I have found for learning programming and Python. What I love about this course is the focus on real life practice and fast feedback loops. There are 179 assignments to complete, all of which you complete in VS Code. Instant feedback is provided via an auto-marker. This emphasis on practice works perfectly for me. You use the same tools you would use as a software engineer (VS Code), and the same approaches (building to meet a suite of tests, later graduating to creating the tests yourself). I have done numerous other Python courses, but none have kept me as engaged as this one, or succeeded in teaching me in a way that has actually got the knowledge to stick. Maths preparation In my maths preparation, I was not quite as lucky as I was with Python. But eventually, I stumbled on three excellent resources: 1. 3Blue1Brown A friend of mine is an A-level maths teacher. His advice to me is that it\u0026#8217;s much more important to understand the principles that mathematical formulae are trying to explain, than it is to be great at memorising formulae and solving equations. Another friend advised me to think visually. When a formula changes, try to visualise how lines or shapes respond to the change. 3Blue1Brown was recommended to me by a software engineer at work. This is THE YouTube channel for anyone trying to learn maths, and wants to do so in a highly visual and practical way. Grant Sanderson is the man behind the channel. He has helped me build a much better understanding of topics in Linear Algebra and Calculus. I\u0026#8217;ll be coming back to these videos when I move on to more advanced AI topics such as neural networks in my degree! Read the comments under his videos \u0026#8211; I am not his only fan. 2. Paul’s Online Notes Paul teaches algebra and calculus at Lamar University. He has kindly made many of his notes and practice problems available online. These are tough topics to learn. But the large quantity of practice questions with answers and thorough explanations are an invaluable resource to someone who learns by doing. Which is the only way of learning a topic like maths! I recommend combining Paul\u0026#8217;s Online Notes with 3Blue1Brown\u0026#8217;s videos. 3. Probability for Data Science Probability and statistics are very important in AI and data science. I did not do enough preparation on these topics before starting my degree, and I had to study intensively to catch up once the course started. The best content I have found is Stanley H. Chan\u0026#8217;s Probability for Data Science book. Like everything in this blog post, it is online and free. Sadly, the answers to practice questions are unavailable. But the explanations in the book are excellent. Using AI to learn AI has also become a far more effective interactive learning resource over the past year, and I am sure it will only get better in the years ahead. In learning step by step with AI, I wrote about some of the prompts I am using to help me learn difficult topics, and about how I am using quiz mode to do regular practice. Give the post a read if you are interested. How am I doing? So far so good! If I keep the grade average I have so far, I will be on track for top marks in this degree. ","permalink":"https://alaniswright.com/blog/from-python-to-pythagoras-preparing-for-an-msc-in-ai-as-a-ppe-graduate/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  Six months ago I started an MSc in Artificial Intelligence at the University of Bath. Six months before that, I began a crash course in Python and mathematics. This blog post covers the best free resources that I found most helpful. If you are preparing for a degree in AI or computer science and you are from a non-technical background, this post is for you.\n\u003c/p\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"my-background\"\u003eMy background\u003c/h2\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  My undergraduate degree was a BA in a non-STEM subject (Economics, Politics and International Studies \u0026#8211; not quite PPE but nobody knows what EPAIS stands for). I have been working as a product/program manager in tech for more than 15 years, but have had limited exposure to mathematics and programming, either academically or professionally.\n\u003c/p\u003e","title":"From Python to Pythagoras: preparing for an MSc in AI as a PPE graduate"},{"content":" Product analytics is one of Claude\u0026#8217;s superpowers. Being able to quickly crunch through product and analytics data means I can make decisions faster, in a more data driven way and with less dependence on the team. Here are 6 ways I am using Claude to help me analyse data. To celebrate the Bayeux Tapestry arriving at the British Museum and me having the foresight to buy my girlfriend a museum couple’s membership for her birthday, here’s a medieval view of Claude connected to all my tools for some “data analysta”\n1. Replacing Dependencies: Claude as a Personal Data Analyst In my post about Using Cursor and MCP as a Product Manager I wrote about using Cursor to explore analytics in PostHog, document findings in Notion or Google Sheets, and draft tickets for the team in Linear. All without me leaving the Cursor UI. I am now doing all of this in Claude Cowork instead. Good documentation is one thing that massively improves Claude\u0026#8217;s data analysis capabilities. Unlike many humans (myself included), Claude actually reads and sometimes even follows instructions! Our data scientists have written a Claude skill shared organisation wide which captures all the best practice ways of working with our analytics. I grew used to the answer of \u0026#8220;have you tried asking Claude\u0026#8221; when I asked data scientists for support with analytics, and am now fielding most queries myself via Claude. This frees them up to focus on higher value activities, and helps me get the information I need faster. 2. Validating UI Risks: Analysing Document Title Legibility Many of the entries in our database contain more than one document. In our passage search UI, I worried that document titles alone wouldn\u0026#8217;t be enough to help a user distinguish between text passages from different documents. I even had work planned for the team to fix this. Instead, using Claude, I analysed all our document titles. I found that most of the variation in document titles was at the beginning of the string, making it easier for users to distinguish documents by title alone. Extra metadata did improve the situation, but not by enough to justify the extra effort and elements on the screen. I was able to resolve this risk myself without asking anyone to build anything. 3. Unlocking Insights Across Multiple Datasets There is an excellent InBetweeners episode where jay says \u0026#8220;BEEPITY BEEP BEEP\u0026#8221; every time Simon mentions his new girlfriend Tara. At one stage, I joked about doing the same thing every time our lead data engineer Fred mentioned the data lake. But now that the data lake is in place, it\u0026#8217;s clear to me what an amazing tool this is. Having all of our product databases and product analytics available to query together in one place has unblocked some valuable insights. For example, with a little help from Claude I was able to analyse the relationship between document metadata and the documents that users are most likely to visit and come back to. There is a strong correlation between document summaries existing above a minimum size and engaged usage. This insight has helped shape the direction of my product strategy. 4. Understanding Document Text Quality HTML is accessible. PDFs very much are not! I wanted to understand whether the text data extracted from PDFs in our database was of good enough quality to recreate the document in a HTML user interface. I extracted full passage text via Snowflake from a sample of documents and loaded them into Claude. Claude\u0026#8217;s analysis of this data helped me spot data issues for the team to prioritise in the next round of text quality improvements. Claude also helped me turn it into a HTML prototype for me to see how it looked for myself. Read more on this in my post on Claude Design. 5. Deciding Defaults with Advanced Query Analysis Search at Climate Policy Radar enables users to search the full text and detect mentions of 100+ topics in the text of documents via an awesome set of text classifiers. It is a powerful feature, but it is not one I have seen before in many other products. It is not a feature users expect, so there is no normal way of doing it. I had a difficult decision to make about what the default logic should be for when users start combining classifiers (e.g., AND vs OR operators, the level at which co-occurrence should occur, interaction with free text search). My work buddy Anne (policy analyst, whose great work I am shamelessly mentioning in this post) used Claude to run through the product analytics, identifying how many and which type of users were affected by this decision. Claude also crunched through search logs, categorising different searches by which default would have likely given the user a better set of results. This deep analysis changed my mind about some of the big assumptions I was making, gave me the evidence I needed to make some tough product calls around what not to build, and the data to get the team and stakeholders on board with the decision. 6. Claude as a Thought Partner Another powerful use of Claude is to help me brainstorm what I should be measuring, and critique my existing ways of measuring product performance. I recently took stock of the end-to-end metrics I was tracking across our full product lifecycle. A deep chat with Claude helped me realise that my core engagement and retention metrics were too tightly coupled with user acquisition metrics. I digested the conversation, consulted with our data scientists, and we are now evolving our top line metrics in response. Knowing when to ignore Claude is still very much a key skill. If I had followed every recommendation, we would have bloated analytics which tracks many of the wrong things. But I like to think of myself as an expert user who knows my domain, and I frequently find Claude a great thought partner in both strategy and execution. Parting Thought Putting analytics and product data in one place. Documenting it so it\u0026#8217;s understandable. Chatting with the data via Claude to generate valuable insights. Generating digestible summaries for my team. These approaches have helped me get so much more out of AI than I was this time last year, and is making me a better product manager. Regardless of whether you are using Claude, Codex or Cursor, I\u0026#8217;d strongly recommend giving this a try if your work involves analysing data. More Importantly, some InBetweeners Trivia The actors who play Simon and Tara in InBetweeners are actually together in real life! They have been for more than 15 years and are engaged. I stumbled on this amazing fact whilst trying to find a good images of \u0026#8220;BEEPITY BEEP BEEP\u0026#8221; for use in this blog post, which was surprisingly difficult to do. The InBetweeners Simon \u0026amp; Tara are Engaged in Real Life! Source: Yahoo\n","permalink":"https://alaniswright.com/blog/6-ways-i-use-claude-for-data-analysis/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  Product analytics is one of Claude\u0026#8217;s superpowers. Being able to quickly crunch through product and analytics data means I can make decisions faster, in a more data driven way and with less dependence on the team. Here are 6 ways I am using Claude to help me analyse data.\n\u003c/p\u003e\u003cfigure class=\"wp-block-image size-large\"\u003e\n\u003cp\u003e\u003ca href=\"https://alaniswright.com/wp-content/uploads/2026/08/ClaudeDataAnalystBayeuxTapestry-scaled.jpeg\"\u003e\u003cimg loading=\"lazy\" decoding=\"async\" width=\"1030\" height=\"562\" src=\"https://alaniswright.com/wp-content/uploads/2026/08/ClaudeDataAnalystBayeuxTapestry-1030x562.jpeg\" alt=\"\" class=\"wp-image-1346\" srcset=\"https://alaniswright.com/wp-content/uploads/2026/08/ClaudeDataAnalystBayeuxTapestry-1030x562.jpeg 1030w, https://alaniswright.com/wp-content/uploads/2026/08/ClaudeDataAnalystBayeuxTapestry-300x164.jpeg 300w, https://alaniswright.com/wp-content/uploads/2026/08/ClaudeDataAnalystBayeuxTapestry-766x418.jpeg 766w, https://alaniswright.com/wp-content/uploads/2026/08/ClaudeDataAnalystBayeuxTapestry-1536x838.jpeg 1536w, https://alaniswright.com/wp-content/uploads/2026/08/ClaudeDataAnalystBayeuxTapestry-1500x818.jpeg 1500w, https://alaniswright.com/wp-content/uploads/2026/08/ClaudeDataAnalystBayeuxTapestry-705x385.jpeg 705w, https://alaniswright.com/wp-content/uploads/2026/08/ClaudeDataAnalystBayeuxTapestry-2048x1117.jpeg 2048w, https://alaniswright.com/wp-content/uploads/2026/08/ClaudeDataAnalystBayeuxTapestry-450x245.jpeg 450w\" sizes=\"auto, (max-width: 1030px) 100vw, 1030px\" /\u003e\u003c/a\u003e\u003cfigcaption class=\"wp-element-caption\"\u003e\u003cem\u003eTo celebrate the \u003ca href=\"https://www.bbc.co.uk/news/articles/cly9r54e5r4o\"\u003eBayeux Tapestry\u003c/a\u003e arriving at the British Museum and me having the foresight to buy my girlfriend a museum couple’s membership for her birthday, here’s a medieval view of Claude connected to all my tools for some “data analysta”\u003c/em\u003e\u003c/figcaption\u003e\u003c/figure\u003e\u003c/p\u003e","title":"6 Ways I Use Claude for Data Analysis"},{"content":" We recently jumped on the Claude bandwagon at Climate Policy Radar and got a company subscription. As luck would have it, that coincided with the launch of Claude Design. It has been a fun few months! In this post, I share how I am quickly building interactive low-fidelity prototypes with Claude Design to test ideas and get feedback faster. I also give some examples of how this has helped me to do better product work. How I use Claude Design I usually follow the same 4-step workflow when prototyping with Claude: Step 1: The Brief I never open Claude Design without a solid brief. Instead of typing a long prompt from scratch, I dump all my unstructured thoughts, links, and background context into Claude Cowork and trigger my custom PRD-Writer Skill. This repeatable prompt automatically transforms my raw braindump into a standardized, structured PRD. Step 2: The Data A prototype is only as good as the data powering it. Rather than relying on generic \u0026#8220;Lorem Ipsum\u0026#8221; or fake data, I work with Claude to pull actual data directly from our data lake. Real data uncovers edge cases that clean dummy data easily hides. Where real data doesn\u0026#8217;t exist, I ask Claude to generate realistic looking dummy data. Step 3: The Design System The legend that is Henry Franks on our team set up Claude Design with two versions of our design system: our polished production UI and a hand-drawn version. I almost exclusively use the hand-drawn template. Hand-drawn UIs keep feedback anchored on structure and value, giving designers the creative license to figure out how it should actually look and feel. Claude allows you to have multiple design systems. This one is the low fidelity one\nStep 4: Sit back and watch the magic happen I upload the PRD, point Claude to the sample data, select the hand-drawn template, and let it build. Within minutes, I have a fully interactive UI ready for testing. It usually takes a few iterations to achieve what is in my head before it\u0026#8217;s ready for sharing or testing with others. Case studies Here are some concrete examples which show how these capabilities are helping. For context, I lead product for a climate law and policy search platform. We turn long, unstructured PDF documents into structured, searchable data for global decision-makers. Here is how this workflow has played out in practice across four recent scenarios: Case 1: Spotting Data Issues Early (HTML Reader vs. PDF) As a GOV.UK alumnus and general accessibility advocate, I dislike PDFs. Most global laws, however, are trapped in them. I wanted to prototype an in-browser HTML document reader based on text we\u0026#8217;d recently extracted. I needed to understand whether our data could support this type of reading experience, and gain a greater understanding of the shape of the data. I fed real extracted data into Claude Design to render an HTML view alongside the original PDF. The prototype looked great, but not perfect. It helped me understand the gap between where our data is now, and where it needs to be to enable the type of reading experience I have in mind for our users. It also exposed an issue with how our data was structured. Seeing the data rendered visually allowed us to catch UX and data quality issues early. One of my HTML document page prototypes\nCase 2: Resolving Internal Navigation Debates We have over 100 machine-learning classifiers mapped to our knowledge graph. We have had many internal debates about how users should navigate this non-linear data, with strong opinions all round. Should we force it into a hierarchical tree? How do we handle multi-category items? Should every node in the tree be a text classifier? Many of the options would require weeks of data manipulation to enable, so this was not a decision that we wanted to get wrong. Many a notion document was written on the topic. To break the deadlock, I generated three distinct navigation prototypes in Claude Design, based both on the data we had and the data we could have. Claude Design is collaborative, so other team members jumped in, tweaked my versions, and added their own. We quickly realised some of our bets just didn\u0026#8217;t work, and some of the risks we were worrying so much about didn\u0026#8217;t seem that risky after-all when we saw them in the light of day. We are now more confident on the future direction is and is not. Critically, we have a way to quickly generate and test prototypes with users. One of the 6 topic navigation prototypes we generated.\nCase 3: Vision Prototyping I like to give the team and senior leaders a sense of where the product is heading years from now so that we can align on the long term direction, generate excitement and make it easier to secure buy-in. Articulating a multi-year product vision usually means static slide decks or \u0026#8220;postcards from the future.\u0026#8221; Recently, while exploring a major new capability, I used Claude Design to build interactive vision prototypes. Even though the underlying APIs and data structures don\u0026#8217;t exist yet, Claude generated realistic interactive flows using synthetic data. Prototyping with senior stakeholders helped me get the ideas out of their heads and into a form we could all see, and helped us align around the future state we wanted to target. Being able to walk through dynamic and clickable interfaces helped us secure buy-in and minimise risk of misalignment. Vision prototypes like these are a good example of where it might make sense to use the high fidelity design system in Claude rather than the hand drawn one. I can see huge potential in using prototypes like these in pitch decks. Case 4: Failing faster and cheaper As our database grows to include a wider variety of documents, I was worried users would hit \u0026#8220;zero results\u0026#8221; dead ends and assume our tool was broken. The textbook response is faceted search \u0026#8211; a dynamic search which responds to the searches a user already has in place before a user clicks. I thought it was a must-have feature. I decided to test the core assumption with Claude. I augmented our existing data with realistic synthetic data capturing the new data types we were planning to bring in and built two side-by-side low-fi prototypes: one faceted, one plain. Quickly testing both prototypes made it clear to me that it wasn\u0026#8217;t a must have after-all. At least not yet. It was a classic case of a product manager overthinking a problem. Prototyping with realistic data enabled me to figure this out faster and cheaper than I otherwise might have. Why I’m Not Deploying Code to Production. Yet… With AI tools making code generation trivial, it\u0026#8217;s tempting to ask: why stop at low-fi prototypes? I am still not writing production code. The one step forward we might gain by having me ship features solo would be offset by three steps back: Pushing AI slop into our codebase creates technical overhead that developers have to clean up. If I don\u0026#8217;t have the skills to be held accountable for the code I commit, then I shouldn\u0026#8217;t be committing it. Bypassing designers and engineers risks damaging team trust and downgrading the quality of our product. Every hour I spend acting as a second-rate developer or designer is an hour I’m not spending on strategy, discovery, user research or team alignment. However, never say never. I can imagine a world where: The guardrails around AI tools and the alignment with our codebase makes it possible for me to write code that is understandable and maintainable by our engineers. Designers and engineers want me to be pushing low risk and experimental features myself, so that they can focus on the bigger problems. The costs of delay and translation exceed the costs of JFDI. Overall, I love that Claude Design lowers the cost of discovery. For me right now the value lies in failing faster and cheaper together, not in replacing the cross-functional team with a one-man-band. ","permalink":"https://alaniswright.com/blog/prototyping-with-claude-design/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  We recently jumped on the Claude bandwagon at Climate Policy Radar and got a company subscription. As luck would have it, that coincided with the launch of Claude Design. It has been a fun few months!\n\u003c/p\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  In this post, I share how I am quickly building interactive low-fidelity prototypes with Claude Design to test ideas and get feedback faster. I also give some examples of how this has helped me to do better product work.\n\u003c/p\u003e","title":"Prototyping with Claude Design"},{"content":" I recently started a part time MSc in AI. So, it probably won’t surprise you to hear that I am having some success using AI to help me learn! There is a lot of maths in computer science and AI. The last time I had any formal maths education was more than 20 years ago, so I am understandably a little rusty. To bridge the gap, I am using Gemini to teach me step by step. Here is how: 1. Ask the question. I have set up a \u0026#8220;Gem\u0026#8221;. This is Gemini’s word for a custom prompt template. To start, I select the Gem from my menu bar, then I either copy and paste a question or upload a photo of the relevant page in a textbook. I am really impressed with how quickly and accurately text is extracted from those photos. 2. Understand the answer. Every time I ask for help with a maths problem, Gemini explains the answer to me, showing exactly how it gets to the solution. So far, I have only used it with questions where I already know the answer just so I can verify its accuracy. It has been 100% correct so far—which is a lot better than my own score! 3. Answer follow-up questions. After solving the initial question, it asks me follow-up questions to check my understanding of the underlying mathematical theorems. It points out any mistakes or gaps in my reasoning and keeps trying to explain the concept in different ways until I get it right. Once I understand the theory, it challenges me with questions similar to the original, gradually increasing the difficulty as I get answers right, or slowing down to reinforce the basics if I get them wrong. Screenshot of my mobile maths teacher\nLearning from lecture notes or YouTube videos is not my style. I learn best by doing. This interactive approach really works well for me. One big quality-of-life improvement to this setup was instructing it to make all the answers multiple choice. Try typing predicate logic symbols on your phone keyboard if you want to experience firsthand why this is a good idea! This makes it much easier for me to learn on the go, which is pretty useful given that I am managing this degree around a full-time job and being a proud (cat) dad of three needy kittens. The reusable prompt is below if you want to give it a try. (Note: There is also a similar “Learn Step by Step” mode available in Perplexity) Prompt Use Learn Step by Step tutoring mode for this maths problem. I’m an MSc AI student. For all questions you ask me, use multiple choice so that it is easy for me to respond on mobile.\u0026nbsp;\u0026nbsp; 1. Start by solving the problem step‑by‑step, naming each rule or theorem and explaining why it applies\u0026nbsp;\u0026nbsp; 2. Ask me follow up questions to check my understanding of the rules and theorems. One question per prompt. Keep going until you are confident I understand the solution well enough to answer some new questions. 3. Point out any mistakes or gaps in my reasoning\u0026nbsp;\u0026nbsp; 4. Ask me new questions similar to the original. Ask each question one at a time.\u0026nbsp; If i make any mistakes, go back to step 2. Gradually increase the difficulty of the questions you ask Daily practice with quiz mode Learning is one of those things where doing a little bit every day goes a lot further than intense burst of activity. To help ensure that what I learn actually sticks, I have set up a second Gem. This one gives me a 10 question multiple choice quiz on all of the maths topics I\u0026#8217;ve learned so far. It utilises quiz mode, a great learning feature that is built into Gemini. When I get questions wrong it explains the answer. It explains the questions I got wrong, and evaluates my strengths and weaknesses. I highly recommend this approach to anyone trying to learn a new skill! Me getting loads of questions wrong in quiz mode. Practice makes perfect (so I’m told!)\n","permalink":"https://alaniswright.com/blog/learning-step-by-step-with-ai/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  I recently started a part time MSc in AI. So, it probably won’t surprise you to hear that I am having some success using AI to help me learn!\n\u003c/p\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  There is a lot of maths in computer science and AI. The last time I had any formal maths education was more than 20 years ago, so I am understandably a little rusty.\n\u003c/p\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  To bridge the gap, I am using Gemini to teach me step by step. Here is how:\n\u003c/p\u003e","title":"Learning step by step with AI"},{"content":" Vibe coding. Hard to believe this was first coined in February 2025, as it\u0026#8217;s a phrase I have heard more than almost any other in recent times. The only thing surprising about it being the\u0026nbsp;Collins Dictionary 2025 Word of the Year\u0026nbsp;is that it is actually two words. What is vibe coding? British royalty might say \u0026#8220;One \u0026#8216;vibe codes\u0026#8217; when one describes what one wants in natural language to an AI tool and it writes the code on one\u0026#8217;s behalf.\u0026#8221; This is a really exciting prospect to a novice coder like me. There are many vibe coding product managers out there working in more advanced ways than me, but I am already seeing these tools have a great impact on how I work. This post covers my experience of vibe coding so far: the tools I have used, the opportunities and risks as I see them, and some of the things I have vibe coded along the way. EDIT: 3 months is a long time in the World of AI! My recent post on prototyping with Claude design covers use of vibe coding for product discovery in more depth. Gemini’s attempt at creating a low fidelity old cartoon sketch of me vibe coding with two tabby cats sleeping on my desk.\nVibe coding tools Late last year I got a Lenny Product Pass. For £300, this has given me one year of free access to Lovable, Bolt and Replit (amongst others). These are AI-powered platforms designed to turn natural language prompts into working web applications available on the internet, with minimum friction. Some powerful capabilities I have observed in these tools: Instant visual feedback. Enter a prompt, and within minutes you can see something interactive on the screen. Clarification questions. These AI tools are interactive, often stopping to ask me questions before burning through lots of credits. Automatic handling of hosting, databases, authentication and deployment. I would struggle to build these things from scratch myself. Agentic testing of web applications. After responding to a prompt, some of these tools will start testing the app against my new or previous requirements, checking to see the requirements have been met and that there are no regressions. If it spots regressions, it will try to fix them. I also use IDEs like Cursor and VS Code for simpler tools and automations. But I would highly recommend giving these vibe coding tools a spin if you want a taste of where AI-assisted software development is heading. Properly explaining what you want is a key skill for anyone managing humans or instructing AI tools. I have written a general post about this before in prompt engineering for product managers. For specific guidance on vibe coding I suggest checking out Vibe Coding Best Practices by Teresa Torres. Opportunities Communicating direction to the team. Sometimes I have an idea in my head that I want to get across. A solution that I want the team to consider. I am no artist. People can barely even read my handwriting. So using AI tools to share my vision can be a great way for me to communicate. A clickable prototype of my vision for user accounts in our product, complete with a health warning or two.\nLightweight tooling. This is the opportunity I have made the most use of. There are so many examples where vibe coded solutions have helped me do something 10x faster, or that I wouldn\u0026#8217;t have been able to do without AI. For example, I had four 2,000 row JSON files I needed in a spreadsheet with duplicates merged. I also merged product analytics with document metadata to identify which types of documents get the most visits from users, validating assumptions around which datasets we should prioritise. Either of these jobs would have taken me hours of wrestling with Google Sheets or Python, or requesting help from a member of the team. Other examples include cleaning up messy datasets, analysing survey data, complex product analytics queries, sourcing new content, synthesising research and competitor analysis. Being able to do these little things myself makes me so much faster. Check out\u0026nbsp;Using Cursor and MCP as a Product Manager\u0026nbsp;for more on this. Testing value hypothesis with users faster. The democratisation of building makes it easy to build prototypes and deliver value to users faster. I built a simple \u0026#8216;climate policy counter\u0026#8217; web app, an interactive data visualisation tool that stakeholders could use to quickly access key stats and growth trends. This was solving a known problem for users, but requests to update the dataset that powers it months after it was built still put a smile on my face. In another example, I used spreadsheets generated by deep research agents to test whether AI-assisted document sourcing could identify content missing from our database. It proved valuable to our content curators \u0026#8211; saving them hours and helping them to find more relevant content. This is not a scalable solution, but it was enough to validate the concept before investing engineering time and thinking about less model-intensive ways of solving the problem at scale. It is also a good example to illustrate that even in the age of vibe coding, there are often good ways to validate hypothesis without AI needing to write any code at all. My recent post on prototyping with Claude design goes into more detail on some of these examples. A clickable tool enabling users to see data growth over time.\nThe thing that most excites me about AI tools for product development is seeing how the wider product team can build and prototype faster using AI, rather than trying to do it all myself. I have seen some amazing prototypes shared by all sorts of different people in our team \u0026#8211; from product designers to policy analysts. And I hope to see more as people get more used to using these tools. On a personal note, I have a lot more good stories to tell about vibe coding internal tools than I do for end user facing capabilities. This is an area where I would really like to learn and do more, and there are many examples out there of people vibe coding in more advanced ways that me. However, I question whether this is the right thing to do with my time. More on that in the risks section. Building production apps. More and more I am hearing about product people who are vibe coding real life production apps, or contributing to the codebase in production grade products. I am not there yet. But this feels like a direction of travel, especially if/when vibe coding tools become more trusted and reliable. One element of this that I am already looking at is having product documentation like PRDs closer to the code. If we have AI agents helping in the writing, reviewing and testing of code, requirements documents like these would serve as excellent context. I have enjyed vibe coding some simple personal projects where the risk is low or I have the technical capability to maintain the end product myself without dependency on AI. But I am generally avoiding it otherwise for now. Two good examples are my girlfriend\u0026#8217;s website \u0026#8211; a single page app built in Lovable and converted to HTML/CSS \u0026#8211; both of which I am comfortable with. And this blog, which I am exploring moving to a static file generator like Hugo, where risk can more easily be controlled because all the files are static. My girlfriend’s website. If anybody needs a Cantonese speaking nutritionist in the Kingston upon Thames area, this might be for you.\nGlimpse of the future. Product managers operate at the intersection of the business, the user and technology. Understanding where technology is going helps us spot opportunities for improving our products. Vibe coding tools are operating at the edge of what is possible right now with AI powered tooling. Some of the capabilities I have seen give me good ideas for how I could improve my own products \u0026 processes. Agentic quality assurance testing is a great example of this. Integrating some of the automated testing capabilities I have seen in vibe coding tools with the products my team is building could help us spot bugs or usability issues before one of our team members or users do. That would be a real progress accelerator. Risks Dilution of focus. As a product manager, I am responsible for helping the team understand our vision, strategy, users, problems to solve and desired outcomes. Vibe-coded products or prototypes from product managers are a poor substitute for an empowered cross functional product team who understand their users and mission. I understand why product managers in early stage startups or hybrid product/design roles are spending serious hours vibe coding. I enjoy being more involved in building, and I think I add value there. But as a time-poor product lead in an organisation of 35 people, I think there is a very good case to be made that I add the most value by using the time savings AI gives me to go from good to great at the things I am responsible for instead. The bottlenecks we have now as a product organisation are perhaps not best solved by me vibe coding. Signal vs noise. The power of sketches and wireframes is that they are ugly and minimal. They force us to focus on the concepts that are central to the idea. Sharing vibe coded prototypes or AI generated documents with the team makes people ask the question: which of these bits are your strongly held opinions vs which of it is AI fluff? I have seen AI generated content shared with the team cause confusion and misalignment because of this false precision. Solutionising. There is a fine line between articulating the vision that is in my head and prematurely solutionising with the team. If sharing prototypes with the team, it is important that there is enough psychological safety between the team and the product manager for the team to push back. I don\u0026#8217;t feel like I have much of a problem here as my team seem to disagree with every other word that comes out of my mouth. Regardless, it is something anyone in a managerial or leadership role should be very aware of. One of the things I have experienced often when working with designers is that when I think I have a good solution to a problem, they usually have a better one. So for me, the importance of the product manager/product designer relationship and the critical role good product designer play on a product team is still very much true in the vibe coding era. Blurring of roles and responsibilities. Product managers can now design and code. Product designers can now code and manage. Engineers can now manage and design. This is a risk and an opportunity. It is an opportunity, because it makes it easier for people to speak the same language, to not block each other from making progress, and for everyone to get to \u0026#8216;good enough\u0026#8217; fast in more than one domain. It is a risk, because most people are not good at most of those things, and if you don\u0026#8217;t know what good looks like, it is hard to critically evaluate an AI output in that thing. Now that it is easy for everyone to get to \u0026#8216;good enough\u0026#8217; fast, being able to go from good to great becomes more of a differentiator than it was before. There is also the human side. This is a big technological change that is enabling new and better ways of working. Teams are at the very early stages of figuring out what these are, and in the early stages, lots of mistakes will be made. People will also be fearful \u0026#8211; worrying about what the future of their role looks like. And territorial \u0026#8211; trying to \u0026#8216;protect their turf\u0026#8217; from others. Navigating this is more of a leadership challenge than a technical one. What I’m taking from this There are huge opportunities to do more, better, faster with AI. Such a huge amount of technological change is happening in such a short space of time. Factors such as social/emotional intelligence, psychological safety and a culture of experimentation become more important than ever if trying to realise this value as part of a product team. AI opportunities are particularly great for people who are expert in more than one domain. Improving my knowledge of software engineering and design is something I have enjoyed doing for years. Vibe coding makes me want to spend more time building a cross-functional skillset \u0026#8211; not less. These are such early days, and it is unclear whether AI will live up to the hype. But generative AI already feels like a bigger and more impactful thing than the blockchain or the metaverse \u0026#8211; it has certainly had more of an impact on me and the way I work. My hunch is that if vibe coders can already achieve so much, when the term was only coined a year ago, imagine where we will be in five years. Or ten. Or twenty. I think it is important for people working in product roles to stay curious, experiment with new tools, and keep looking for ways to improve our products and processes. And that is what I am going to continue doing. ","permalink":"https://alaniswright.com/blog/vibe-coding-as-a-product-manager-risks-and-opportunities/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  Vibe coding. Hard to believe this was first coined in February 2025, as it\u0026#8217;s a phrase I have heard more than almost any other in recent times. The only thing surprising about it being the\u0026nbsp;\u003ca href=\"https://blog.collinsdictionary.com/language-lovers/collins-word-of-the-year-2025-ai-meets-authenticity-as-society-shifts/\"\u003eCollins Dictionary 2025 Word of the Year\u003c/a\u003e\u0026nbsp;is that it is actually two words.\n\u003c/p\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  What is vibe coding? British royalty might say \u0026#8220;One \u0026#8216;vibe codes\u0026#8217; when one describes what one wants in natural language to an AI tool and it writes the code on one\u0026#8217;s behalf.\u0026#8221; This is a really exciting prospect to a novice coder like me. There are many vibe coding product managers out there working in more advanced ways than me, but I am already seeing these tools have a great impact on how I work.\n\u003c/p\u003e","title":"Vibe coding as a product manager: risks and opportunities"},{"content":" Here is the latest version of the checklist I use to make sure I don\u0026#8217;t forget anything important when I ship new features or significant changes. Hope you find it helpful! Goals \u0026amp; Quality What were the main goals of this work? Does the solution still achieve them? Has anything visibly degraded for users? Anything that would embarrass me in a live demo? Documentation \u0026amp; Content User FAQs, onboarding flows, and instructional videos updated Training planned for users (if internal tooling) Methodology, data dictionary, and technical READMEs updated Supporting copy elsewhere on the product (tooltips, help text, landing pages) reviewed and updated Known issues and limitations documented Communications Internal: team informed via demo at show \u0026 tell External: relevant stakeholders informed of the change and go-live date Public product roadmap updated Comms: change is considere for comms planning, and comms assets written Testing Analytics and observability instrumentation verified with key metrics tracked User acceptance tests completed per test plan — how will we know this works as expected, on which environments, and who is involved? Performance benchmarks met (load times, API response, error rates) Privacy standards met (if collecting sensitive data) Accessibility standards met Security standards met Rollout Rollout plan defined — phased release, feature flags, A/B test? Rollback plan defined — if something goes wrong, how do we revert quickly? User feedback mechanism defined — how will we collect and act on feedback post-launch? ","permalink":"https://alaniswright.com/blog/definitions-of-done-checklist/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  Here is the latest version of the checklist I use to make sure I don\u0026#8217;t forget anything important when I ship new features or significant changes. Hope you find it helpful!\n\u003c/p\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"goals--quality\"\u003eGoals \u0026amp; Quality\u003c/h2\u003e\n\u003cul class=\"wp-block-list\"\u003e\n  \u003cli\u003e\n    What were the main goals of this work? Does the solution still achieve them?\n  \u003c/li\u003e\n  \u003cli\u003e\n    Has anything visibly degraded for users? Anything that would embarrass me in a live demo?\n  \u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"documentation--content\"\u003eDocumentation \u0026amp; Content\u003c/h2\u003e\n\u003cul class=\"wp-block-list\"\u003e\n  \u003cli\u003e\n    User FAQs, onboarding flows, and instructional videos updated\n  \u003c/li\u003e\n  \u003cli\u003e\n    Training planned for users (if internal tooling)\n  \u003c/li\u003e\n  \u003cli\u003e\n    Methodology, data dictionary, and technical READMEs updated\n  \u003c/li\u003e\n  \u003cli\u003e\n    Supporting copy elsewhere on the product (tooltips, help text, landing pages) reviewed and updated\n  \u003c/li\u003e\n  \u003cli\u003e\n    Known issues and limitations documented\n  \u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"communications\"\u003eCommunications\u003c/h2\u003e\n\u003cul class=\"wp-block-list\"\u003e\n  \u003cli\u003e\n    Internal: team informed via demo at show \u0026 tell\n  \u003c/li\u003e\n  \u003cli\u003e\n    External: relevant stakeholders informed of the change and go-live date\n  \u003c/li\u003e\n  \u003cli\u003e\n    Public product roadmap updated\n  \u003c/li\u003e\n  \u003cli\u003e\n    Comms: change is considere for comms planning, and comms assets written\n  \u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"testing\"\u003eTesting\u003c/h2\u003e\n\u003cul class=\"wp-block-list\"\u003e\n  \u003cli\u003e\n    Analytics and observability instrumentation verified with key metrics tracked\n  \u003c/li\u003e\n  \u003cli\u003e\n    User acceptance tests completed per test plan — how will we know this works as expected, on which environments, and who is involved?\n  \u003c/li\u003e\n  \u003cli\u003e\n    Performance benchmarks met (load times, API response, error rates)\n  \u003c/li\u003e\n  \u003cli\u003e\n    Privacy standards met (if collecting sensitive data)\n  \u003c/li\u003e\n  \u003cli\u003e\n    Accessibility standards met\n  \u003c/li\u003e\n  \u003cli\u003e\n    Security standards met\n  \u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"rollout\"\u003eRollout\u003c/h2\u003e\n\u003cul class=\"wp-block-list\"\u003e\n  \u003cli\u003e\n    Rollout plan defined — phased release, feature flags, A/B test?\n  \u003c/li\u003e\n  \u003cli\u003e\n    Rollback plan defined — if something goes wrong, how do we revert quickly?\n  \u003c/li\u003e\n  \u003cli\u003e\n    User feedback mechanism defined — how will we collect and act on feedback post-launch?\n  \u003c/li\u003e\n\u003c/ul\u003e","title":"Definitions of Done Checklist"},{"content":" Cursor is an AI-powered code editor built for software engineers \u0026#8211; not product managers. Yet over the past few months, it has become my primary AI tool for product management work. Here\u0026#8217;s why I made the switch, and how it\u0026#8217;s helping me get more done. A Case Study (and Some Use Cases) Here\u0026#8217;s a recent example of how I used Cursor end-to-end to investigate and document an analytics issue: Exploring our analytics. I can chat directly with PostHog (our analytics tool) through Cursor. It writes and executes SQL queries, then presents the results to me in plain English. Identifying the root cause of issues. I noticed something unusual in our analytics data. When I asked Cursor to investigate, it autonomously created multiple diagnostic queries, pinpointed the exact date the bug began, and identified the most likely causes. Drafting markdown documentation. Cursor summarised the issue in a markdown file. Like most LLM outputs, it was verbose. I ended up deleting about half the content. But it gave me a solid starting point. Publishing to Notion. Once I refined the writeup, Cursor posted it to Notion and automatically applied the relevant tags \u0026#8211; something most people don\u0026#8217;t do consistently! I manually added an \u0026#8220;AI generated content\u0026#8221; tag-transparency about AI involvement matters to me. Creating a Linear ticket. Cursor created the ticket with a concise description, and assigned it to the correct team and owner. This end-to-end workflow took minutes to go from investigation to documentation to ticket creation. If I was doing this all myself it would have taken hours. More importantly, it all happened without me leaving Cursor. Another case study (and some more use cases) Here\u0026#8217;s how I used Cursor to analyse historical data on a specific user segment and produce a comprehensive report. Searching and summarizing Notion documentation. I needed to compile feedback from a specific user segment. Cursor searched both our user feedback and meeting notes databases in Notion. Surprisingly, it surfaced documents I didn\u0026#8217;t know existed, though it also missed some information I was aware of. Not perfect, but a strong 80/20 solution. Analysing feedback. I had hundreds of survey responses from this segment. After removing PII from the comments, I asked Cursor to design a classification scheme, apply it to all responses, then produce both quantitative and qualitative analysis. It handled the entire analytical workflow autonomously. Some of the classifications I didn\u0026#8217;t think looked quite right, but it was easier to edit something that was mostly correct than it would have been to create it all myself from scratch. Generating data visualisations. Within seconds, Cursor created a beautiful HTML bar chart visualising the key findings. I simply took a screenshot and dropped it into my final report. Consolidating all analysis into a final report. Cursor identified patterns across all the research data. This is where LLMs excel. While my final report looks nothing like Cursor\u0026#8217;s first draft (I rejected most suggestions), it surfaced valuable statistics and observations I incorporated into my analysis. This one still took me a couple of hours to complete. But without Cursor, it either would have taken a lot longer or have been done to a lower standard. Other use cases Writing status updates. For project updates (posted in Linear and synced to Slack), I start with Cursor\u0026#8217;s summary of progress since my last update. I heavily edit these drafts-cutting most of the content. But it prevents me from forgetting important details and eliminates the need to manually review dozens of tickets. I let Cursor be comprehensive, then I ruthlessly prioritise what stakeholders actually need to know. Proofreading. Cursor\u0026#8217;s track changes feature lets me review and approve/reject each suggested edit individually. Combined with a spell-check extension, it\u0026#8217;s become my default proofreading workflow. Critiquing my work. I\u0026#8217;m building a library of prompts that simulate feedback from different expert perspectives (inspired by the Cursor for Product Managers course). This helps me strengthen strategy documents before sharing them with the team. The Power of MCP Connection with third-party tools. MCP (Model Context Protocol) enables Cursor to connect directly with Notion, Linear, and PostHog. This isn\u0026#8217;t just about eliminating copy-paste. Cursor can query these data sources directly, access the full context it needs, and write back to create documentation, tickets, and analytics insights. It\u0026#8217;s the difference between an assistant who reads screenshots versus one with direct database access. It also means that rather than switching between all these tools, I can stay working in one place: Cursor. Here are the MCP servers I am using at the moment. You can control which actions to give Cursor permission to do, and whether or not to approve each individual request to use a tool in a particular way\nHow I stay in control Using AI extensively requires deliberate guardrails. Here\u0026#8217;s how I maintain control: AI generates, I decide. Every edit goes through track changes. I review and approve each modification individually. Nothing changes without my explicit approval. Heavy editing is the norm. I typically cut more than 50% of AI-generated content. Cursor gives me comprehensive drafts; I refine them to what\u0026#8217;s actually important. Transparency about AI use. I label AI-generated content in shared documents. My team should know when they\u0026#8217;re reading AI output versus my direct work. Human judgment on strategy. I use AI for research, analysis, and drafting. But strategic decisions remain mine. AI helps me think better; it doesn\u0026#8217;t think for me. Local storage and version control. All work lives in markdown files on my machine. I can see the full history of changes and revert anything if needed. What Cursor Does Better Than ChatGPT (\u0026amp; Other Similar Tools) Outputs are produced in markdown and stored locally. Everything lives in markdown files on my machine \u0026#8211; not trapped in a chat interface. This means I can directly edit AI outputs, version control them, and iterate without copy/pasting. Markdown is simple, portable, and supports the basic formatting I need. Track changes functionality. Cursor uses the same diff interface engineers use for code review. Every AI suggestion appears as a tracked change I can individually accept or reject. This gives me confidence that nothing changes without my explicit approval. I don\u0026#8217;t have this same confidence when using ChatGPT. Multiple AI models. Cursor supports multiple AI models in one interface. As model capabilities evolve and AI leaderboards shift constantly, I can switch to whichever model performs best for my current task. No need to maintain separate subscriptions or learn different interfaces. One subscription for everything. A single Cursor Pro subscription has the potential to cover all my AI needs at work \u0026#8211; product management, light coding, analysis, searching the web and writing. An example of how Cursor helped me proofread this blog post – and approve each individual change it makes to my document\nOther things Cursor does Cursor also offers features common to tools like ChatGPT, but worth mentioning: Always considers my product strategy and writing style automatically in every response (via indexed project files). Easy prompt template storage via @ commands. No more maintaining a separate prompt library and copy-pasting-templates live in my project and are accessible with autocomplete. All chats stored for easy reference and continuity. I can pick up exactly where I left off in any previous conversation. Zero data retention policy. AI models don\u0026#8217;t train on my company data-whether from chat or accessed via MCP. Note: This guarantee only applies when using Cursor\u0026#8217;s included LLM credits, not when bringing your own API keys. Intuitive interface. Folder structure left, files centre, chat right. The layout feels natural. I considered alternatives like Claude Code (terminal-based), but Cursor\u0026#8217;s visual interface felt easier than using terminal. Weaknesses of Using Cursor as a product manager MCP servers frequently disconnect and require re-authentication. This can be frustrating when you\u0026#8217;re in the middle of a complex task. No cross-session context memory. Unlike ChatGPT\u0026#8217;s memory feature, Cursor doesn\u0026#8217;t automatically learn from past conversations to understand my preferences and context. Chat history is saved locally, but the AI doesn\u0026#8217;t build a persistent understanding of me across sessions. This may be coming in a future update, but for now, each conversation starts relatively fresh. How you can get started If you want to get started with using Cursor yourself or you want to learn more, here are the two resources I recommend: Cursor for Product Managers: Learn Cursor IN Cursor!This brilliant free introductory course teaches you how to use Cursor, in Cursor. As well as being an excellent course, this is a fascinating insight into the potential for AI tooling to support good course design. This podcast from How I AI is what first got me interested in the idea of using Cursor as a product manager: \u0026#8220;Cursor is a much better product manager than I ever was\u0026#8221;: How this PM uses AI for PRDs, Jira tickets, and replying to coworkers | Dennis Yang (Chime). Recommended extensions for Cursor Spell Checker \u0026#8211; Catches typos in real-time as you write markdown documents. Editable Markdown Preview \u0026#8211; Allows you to edit markdown whilst seeing how it will look. ","permalink":"https://alaniswright.com/blog/using-cursor-and-mcp-as-a-product-manager/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  Cursor is an AI-powered code editor built for software engineers \u0026#8211; not product managers. Yet over the past few months, it has become my primary AI tool for product management work. Here\u0026#8217;s why I made the switch, and how it\u0026#8217;s helping me get more done.\n\u003c/p\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"a-case-study-and-some-use-cases\"\u003eA Case Study (and Some Use Cases)\u003c/h2\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  Here\u0026#8217;s a recent example of how I used Cursor end-to-end to investigate and document an analytics issue:\n\u003c/p\u003e\n\u003cul class=\"wp-block-list\"\u003e\n  \u003cli\u003e\n    \u003cstrong\u003eExploring our analytics.\u003c/strong\u003e I can chat directly with PostHog (our analytics tool) through Cursor. It writes and executes SQL queries, then presents the results to me in plain English.\n  \u003c/li\u003e\n  \u003cli\u003e\n    \u003cstrong\u003eIdentifying the root cause of issues.\u003c/strong\u003e I noticed something unusual in our analytics data. When I asked Cursor to investigate, it autonomously created multiple diagnostic queries, pinpointed the exact date the bug began, and identified the most likely causes.\n  \u003c/li\u003e\n  \u003cli\u003e\n    \u003cstrong\u003eDrafting markdown documentation.\u003c/strong\u003e Cursor summarised the issue in a markdown file. Like most LLM outputs, it was verbose. I ended up deleting about half the content. But it gave me a solid starting point.\n  \u003c/li\u003e\n  \u003cli\u003e\n    \u003cstrong\u003ePublishing to Notion.\u003c/strong\u003e Once I refined the writeup, Cursor posted it to Notion and automatically applied the relevant tags \u0026#8211; something most people don\u0026#8217;t do consistently! I manually added an \u0026#8220;AI generated content\u0026#8221; tag-transparency about AI involvement matters to me.\n  \u003c/li\u003e\n  \u003cli\u003e\n    \u003cstrong\u003eCreating a Linear ticket.\u003c/strong\u003e Cursor created the ticket with a concise description, and assigned it to the correct team and owner.\n  \u003c/li\u003e\n\u003c/ul\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  This end-to-end workflow took minutes to go from investigation to documentation to ticket creation. If I was doing this all myself it would have taken hours. More importantly, it all happened without me leaving Cursor.\n\u003c/p\u003e","title":"Using Cursor and MCP as a Product Manager"},{"content":" I just finished The Complete Agentic AI Engineering Course by Ed Donner on Udemy. It was great! I thoroughly recommend you give it a try if you are interested in learning how to build AI Agents, and prefer to do so via hands-on projects. Instead of building hobby projects, I focused on building AI agents to help me be a better product manager. This post covers my very brief journey trying to build an AI agent that could automate competitor analysis, why I ended up deciding to use the Perplexity app instead, how I am using this capability to help me get more done, and how I hope to improve this capability in the future. Context Competitor analysis is an important task for a product manager. Since it never has deadlines attached, it never has the same urgency as most of the other things I do. I have a Notion database of products I like to keep track of. The most relevant products I try to look at every few months, the less relevant ones I like to look at every year. Whenever someone in the team identifies a product to take inspiration from, we add it to the database for investigation. There are two types of competitor research I like to do: Researching a product for the first time Checking to see what has changed since the last time I checked This post focuses mostly on 2 \u0026#8211; checking on a product I know well to see what has changed since my last round of checks. But I am also using AI to help me research a product for the first time. Evals Most good AI projects start with evals. Evals are the dataset used to objectively test whether AI models have given a good response or not. I started by focusing on a product that I know well. I took an hour to read up on everything they had done in 2025, and played around with their product. I came up with a list of 10 interesting improvements they had made in the past year that looked noteworthy to me. I evaluated my model performance against how many of these 10 improvements were successfully identified. This dataset of 1 is alarmingly small for an AI project. If I was building an AI tool for a user facing product, I would expect to have thousands of these types of test in place. But it beats relying on vibes alone. And for an internal tool where I am the only user, it feels proportionate. Starting out manual Before jumping into code, I decided to try to get good results using the best AI models available at the time of writing. Knowing that I need models which are good at web based research, I decided to try Deep Research mode in both Perplexity and Gemini. After a bit of experimenting with prompts, here are the results: Perplexity: 9/10 Gemini: 6/10 Perplexity was also a lot faster. Off I went to try to build an agent myself in CrewAI! Design CrewAI was one of the AI tools I most enjoyed from the Agentic AI course. A \u0026#8220;crew\u0026#8221; consists of agents who do tasks, which felt very intuitive to me as someone with a background in project management. So I decided to start with CrewAI. I set up a new crew using UV. If you use Python and haven\u0026#8217;t heard of UV, do yourself a favour and take 5 minutes to check out uv is the best thing to happen to the Python ecosystem in a decade. One of the great things about the AI agents course was learning about some of the tools Ed uses when he is working with AI. Tools like UV. Before starting to write my agents and tasks, I decided to get some design advice from Gemini. I asked Gemini to: Identify three agent architectures that could be used to solve my problem Do a SWOT analysis of each, and give them all a score Identify a fourth agent architecture that draws upon the context of the first two questions Re-do the SWOT analysis of each The end result was an approach involving: 3 agents 3 tasks 1 tool connection to allow the agents to search the internet for information Implementation Result of first attempt: 1/10. That means it only found 1 of the 10 improvements that I had found manually. Not very good! To debug the issue, I examined the traces. Traces document the requests made to AI tools and their responses, and are a great way of debugging generative AI systems when they go wrong. I quickly discovered the issue. My first agent \u0026#8211; the one who goes out and collects relevant information from the internet \u0026#8211; was only finding 9 snippets of information. To get round this issue, I instructed this agent to perform multiple web searches. Result of second, third and fourth attempt : 2/10 It took me a few tries to get multiple instances of my agent to go out and do web searches, so that more context could be brought back overall. Still, it struggled. Not enough results were brought back, and not enough context from each. Upon further investigation, I realised that the free version of SerperDevTool I was using only allowed me to retrieve limited information from each source. I had an Exa.AI account for a different project, so I decided to give that a try. Result of retrieving context from web using Exa.AI: 4/10 Getting better! However, there was still a lot of good context being missed. AI tools can only give the right answers if they have the right context to draw on, so unless I could get this right, the rest of the agent would struggle. Pivoting to Perplexity Deep Research I had spent almost a day on this project by this point. Whilst I was learning a lot from my tinkering and experimenting, I couldn\u0026#8217;t help but think it was all bit of a waste of time. Perplexity Deep Research had already achieved 9/10 from my earlier checks. Even if I did succeed in building my own agent to equal Perplexity\u0026#8217;s standard, it was likely to take me a long time to achieve. Given how fast the newest models are improving, I was realising that I may as well just use Perplexity Deep Research Mode for this job. Fortunately, as an OpenRouter user, I can access API keys from most AI model developers, including Perplexity Deep Research. I decided to create a script that would allow me to quickly generate Deep Research reports on similar products, and output the results to markdown so that I could get them into Notion with a few clicks. If this worked, I could automate the script to run every 3 months, giving me quarterly updates. So I decided to create a very simple crew. A crew of one super agent equipped with Perplexity Pro. I gave that agent one task \u0026#8211; the task I had given Perplexity and Gemini right at the beginning. Result of working with Perplexity Deep Research via CrewAI: 8/10 This was not quite as good was what I was able to achieve with Perplexity via their app. But the generative nature of generative AI means the results will never be the same every time. And 8/10 is really not far from 9/10. It was great to generate 8 markdown files that I could easily upload to Notion in just a few clicks. However, of those 8 documents: One only generated a one paragraph response One ignored my formatting guidelines, and created 6x the text of the others The average cost was $1 per report. That\u0026#8217;s pretty high by AI standards My CrewAI agent The task I have assigned to my CrewAI agent\nMy solution (for now) I decided to stick with using the Perplexity Pro App to generate my competitor analysis. Why? It\u0026#8217;s free for me to use the App The time savings from having all the reports generated automatically for me isn\u0026#8217;t that high if some of them randomly don\u0026#8217;t work I have other Agentic AI projects in progress that Deep Research models are less likely to solve any time soon, so I will focus my Agentic AI efforts on those instead. More about those in another post! A no code solution makes it easier to share this capability with non technical members of my team Prompting via the app seems less temperamental than prompting via the API How does this help me do my job? Right now, according to my alarmingly small evaluation dataset, I am better at doing competitor analysis than AI is (10/10 beats 9/10). However: AI is much faster than me 10/10 isn\u0026#8217;t much better than 9/10 AI is getting better all the time It is not a competition. Alan + AI is better than Alan or AI alone Competitor analysis is also not something a good product manager should outsource entirely to AI. The scores out of 10 above don\u0026#8217;t capture the extra context I get from using similar products myself. So I take a few minutes to read these reports. I click on the links that look interesting, and spend a little time trying out the product for myself. I add screenshots of interesting things I find to the report, and add comments as I go so that I can refer back to the bits I find most interesting at a later date. TABLE\nAlan: Relevant improvements found: 10/10. Time taken: 1 hour\nAI: Relevant improvements found: 9/10. Time taken: 1 minute\nAlan using AI: Relevant improvements found: 10/10. Time taken: 15 minutes Next steps Here are some extra capabilities that I plan to explore in the future: Auto publish reports to Notion I have not tried the Perplexity/Notion integration yet, but one thing I would like to try soon is automatically publishing research to Notion, and using the context from previous research I have done to minimise the sharing of duplicate information. Be sure to turn off AI data retention in Perplexity if you give this a try, as I can\u0026#8217;t imagine any employer wants the contents of their file management system used as training material for AI tools. Using context from previous reports for future reports Every 3 months when I read these reports, I expect to come across lots of duplicate information. It would be nice if new reports automatically excluded information that I had read before. Or at minimum, tagged it as potentially duplicate information. Screenshots of key features Agents are increasingly able to browse the web and click around as a human would. I would love to see the reports I generate include screenshots of key features. I am tempted to try to build an agent myself that does this. But I do not think it is long before this capability comes to Deep Research mode, or one of the AI powered web browsers like Perplexity\u0026#8217;s Comet or OpenAI\u0026#8217;s Atlas that have been launched recently. ","permalink":"https://alaniswright.com/blog/using-ai-for-competitor-analysis/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  I just finished \u003ca href=\"https://edwarddonner.com/2025/04/21/the-complete-agentic-ai-engineering-course/\"\u003eThe Complete Agentic AI Engineering Course\u003c/a\u003e by \u003ca href=\"https://edwarddonner.com/\"\u003eEd Donner \u003c/a\u003eon Udemy. It was great! I thoroughly recommend you give it a try if you are interested in learning how to build AI Agents, and prefer to do so via hands-on projects.\n\u003c/p\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  Instead of building hobby projects, I focused on building AI agents to help me be a better product manager.\n\u003c/p\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  This post covers my very brief journey trying to build an AI agent that could automate competitor analysis, why I ended up deciding to use the Perplexity app instead, how I am using this capability to help me get more done, and how I hope to improve this capability in the future.\n\u003c/p\u003e","title":"Using AI for competitor analysis"},{"content":" I recently switched to the EE mobile phone network, mostly because they reportedly have the best 5G network in the UK. While I\u0026#8217;ve had to reroute my favourite park walk to avoid a pesky signal dropout spot, the service has mostly lived up to the hype. The real bonus though, was getting free access to Google AI Pro. That\u0026#8217;s excellent timing, as Google\u0026#8217;s AI products have really taken off this past few months. Here are some of the ways I\u0026#8217;ve been using my new subscription. Image editing One of the things that made me nervous about cancelling my ChatGPT subscription was the lack of image editing functionality in the Google ecosystem. Here is Google\u0026#8217;s hilarious attempt to put me in a Where\u0026#8217;s Wally image. Kind of misses the point of the cartoon\u0026#8230; Gemini response to the prompt: “Put me in a wheres wally image. Attached is me”\nAs you can see I had every reason to be afraid of Google\u0026#8217;s image related AI capabilities. But in September, something big happened. Nano Banana launched. And wow. Nano Banana is Google\u0026#8217;s image editing AI model. What impressed me most was its seeming ability to only edit the specific part of the image you want it to, while leaving the rest untouched. In 6 ways I like to use ChatGPT, my girlfriend and I wanted to see what our future kids might look like. Notice how it added two realistic-looking kids. But it changed us into different people. And most other parts of the photo. Prompt: Create a realistic image of a family. The two people in the photo as parents. With their 2 children – boy and girl. Blend features from both parents.\nSee below the response from Nano Banana to the same prompt. Same prompt as in the image above!\nIt saddens me that the kids clothes don\u0026#8217;t match ours anymore. But it has done a much better job of not changing us into different people. It has even kept the background the same. This is a big improvement from the ChatGPT version. Though if you run the prompt a few times, we do eventually change into different people again. And I am still left wondering what our kids will actually look like, as ChatGPT and Gemini seem to be miles apart here. I might need to bring in Claude as the judge! Google suite integration As a Google Drive user, the ability to use Gemini (Google\u0026#8217;s leading generative AI model) in Google Sheets is a massive timesaver. I no longer Google for formulas. I ask Gemini to write them from within Google Sheets. This is a big time saver, as copying and pasting spreadsheet formulas is never a simple copy and paste. Email drafting is another valuable feature. Gemini\u0026#8217;s suggested responses are often right on the mark, and even when they need editing (which they often do), they provide a great foundation to work from. I also value the ability to easily export results from Gemini chat directly into the Google suite. However, this isn\u0026#8217;t always perfect. Lately, I\u0026#8217;ve run into an annoying issue where complex tables won\u0026#8217;t export or copy/paste properly into Google Sheets. The workaround involves converting them to CSVs, downloading, uploading to Drive, and then converting them again. Poor me, right? Get out the world\u0026#8217;s smallest violin! Deep research When you use deep research mode, instead of starting to give you a response within seconds, the model will take time to think. It will first break down your question into a step-by-step research plan. You can edit the research plan to get it right before continuing. It will then work through the research plan step-by-step, conducting google searches along the way to gather information from the web that might be relevant to the question. Research plan for a report I asked it to write for me on theories of information seeking behaviour I have used deep research mode thoroughly at work to help me with jobs such as: Competitor analysis Product comparisons Critiquing strategy decisions Briefing me on product domains as part of discovery research Sourcing hard to find documents for a database (and generating metadata) Three things I find great about Gemini deep research compared to ChatGPT: Speed. Gemini usually responds in minutes. ChatGPT often takes 30 minutes or more to answer questions Understanding user intent: ChatGPT seemed to ask followup questions every time, even if the answer is obvious from my prompt. Gemini\u0026#8217;s research plan helps me validate that my intent has been understood, and quickly correct it if it has not. Google suite integration: quickly getting results into Docs or Sheets saves a lot of copying, pasting and formatting losses One thing that could be improved: it can be verbose. I often give specific output instructions to LLMs to put results in a table. Gemini often cannot resist giving me a few pages of insight before my lovely tables. Like ChatGPT with the \u0026#8216;always asking followup questions\u0026#8217;, it feels as if deep research mode is trying hard to follow a template in the way it sets out it\u0026#8217;s responses, even if that isn\u0026#8217;t what I am looking for. Or perhaps I am not reading it\u0026#8217;s research plans thoroughly enough! Gemini vs Fantasy Premier League When I play Fantasy Premier League with my mates, I usually win. Those victories come at a cost though \u0026#8211; hours of life lost to obsessively researching the best transfers, questioning who to make captain and deliberating on when to play wildcards. So this year I decided to try something different. I let Gemini play for me. Two days before the start of the season, I started a deep research conversation. I prompted Gemini to first explore the best strategies for winning the game. And then to build me a team to win the season. Every week I then pasted in my current squad and available transfer budget, and asked it to tell me what to do. Things started off well. Up until the end of September I was in the top three in all of my leagues. But since then things have gone downhill rapidly. I\u0026#8217;m now near the bottom of most of my leagues (though above my brothers thankfully). Don’t let those green arrows fool you. There’s only about 15 people in those leagues!\nJokes aside, despite my poor performance, I think this is a task that Deep Research is generally well suited to. The tool\u0026#8217;s access to Google search gave it live access to the latest team selection news on the internet. It frequently recommended changes based on which players were on/off form, and which teams had easy/hard transfers coming up. That is the same process I go through when I am playing the game. It made a few noticable mistakes. It occasionally recommended unviable transfers, suggesting I bring six midfielders into my squad rather than the maximum of five. It also could not read screenshots of my team. Though the fact that I even think I can screenshot an image on my mobile phone and have it identify the names and positions of the 15 players in my squad is a sign of just how high expectations have risen. The biggest issue remains though: it\u0026#8217;s losing! Where have things gone wrong? Sticking with Salah for too long? Not captaining Haaland? Transferring Evanlison in the week he gets injured? Not having enough Bournemouth players in the team (something I have never been guilty of as a Bournemouth fan)? Some speculate that AGI will be here in a couple of years, but AI in 2025 can\u0026#8217;t seem to manage the simple task of beating my friends at this game \u0026#8211; a feat I myself have managed many a time. I’ll settle with this table at the end of the season… Up the Cherries!\nNote on ChatGPT comparisons It\u0026#8217;s probably a tad unfair for me to compare Gemini now to ChatGPT of 3 months ago. A few months is a long time in the world of AI! Other AI blog posts written by me AI prompt engineering as a product manager 6 ways I like to use ChatGPT AI product management in high stakes domains 8 ways I am using AI to help me be a better product manager (and 4 ways I am not) ","permalink":"https://alaniswright.com/blog/google-ai-pro-image-editing-deep-research-and-fantasy-premier-league/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  I recently switched to the EE mobile phone network, mostly because they reportedly have the best 5G network in the UK. While I\u0026#8217;ve had to reroute my favourite park walk to avoid a pesky signal dropout spot, the service has mostly lived up to the hype. The real bonus though, was getting free access to \u003ca href=\"https://one.google.com/intl/en_uk/about/google-ai-plans/\"\u003eGoogle AI Pro\u003c/a\u003e. That\u0026#8217;s excellent timing, as Google\u0026#8217;s AI products have \u003ca href=\"https://www.lennysnewsletter.com/p/how-google-built-ai-mode-in-under-a-year\"\u003ereally taken off\u003c/a\u003e this past few months. Here are some of the ways I\u0026#8217;ve been using my new subscription.\n\u003c/p\u003e","title":"Google AI Pro: Image Editing, Deep Research and Fantasy Premier League"},{"content":" Product teams often face more opportunities than they can act on, with new ones arising all the time. This post explores the link between strategy and priorities, when prioritisation frameworks help or hinder, and how to empower teams to make smart, timely decisions as new opportunities emerge. Too true! Image borrowed from ProductManagerMeme\nWhy strategy must precede prioritisation Effective prioritisation starts with a clear strategy. Without one, even high-value tasks can pull teams in too many directions, diluting impact and slowing progress. If we prioritise without strategy, we focus on lots of different things that are highly valuable in their own right. But when we add them all together, they don’t add up to anything extraordinary. We fail to take advantage of limited resources to achieve maximum impact. “If you prioritise everything, you prioritise nothing”. What makes a good strategy Vision describes the future we are trying to create. Strategy is the plan to achieve the vision. A good product strategy includes: Small point of focus Applied to high value \u0026 under served user needs To get maximum leverage To deliver maximum impact At pace On route to achieving the vision A good product strategy should answer questions like: How do we use our strengths to solve big problems for our target users? What are the many things we don\u0026#8217;t focus on? What are the few things we focus our limited resources on? How do the small number of things we focus on combine together to be more than the sum of their parts and multiply impact? At a high level, what are the big steps forward we need to take to achieve the vision? How do we take the first step? How do we expect the competitive and technological landscape to evolve? How are we going to make the most of the opportunities these changes present? Why I struggle with prioritisation frameworks Product teams often lean on frameworks like RICE, WSJF and 2\u0026#215;2 grids to bring structure to prioritisation. Prioritisation frameworks are helpful when: Choosing between similar types of work with shared context Working in a larger organisation with many stakeholders There is enough data to confidently estimate The decision isn\u0026#8217;t obvious Often these conditions are not met. Especially in tech. Especially in smaller organisations. Prioritisation frameworks I like John Cutler’s miro board workshop for cost of delay is a great way to use the cost of delay framework with a team\nCost of delay. Value, urgency and effort are the three most important factors in prioritisation decisions. Cost of delay is based on these three things. John Cutler\u0026#8217;s miro board workshop for cost of delay is a great way to work through this as a team. For a slightly more mathematical approach, check out this old blog post from me on how Government digital teams can use Cost of Delay to prioritise work (also works well for private sector teams). This framework makes more sense for teams in bigger organisations where there are more strategic goals and competing demands for the team\u0026#8217;s time. Jobs to be done. Most of prioritisation is solving the right problem. One of my favourite ways to prioritise problems to solve for users is to understand their jobs to be done. The best jobs to focus on are ones where the user rates a job as important, but where they are not satisfied with their existing solution. The best way to get this data is by talking to lots of users, but I have also experimented with using jobs to be done surveys to gather this data quantitatively. Bespoke options tables. Most of the time, it is relatively easy to say \u0026#8220;not yet\u0026#8221; to new things that come up. But in fast moving environments, new opportunities or information can arise that make a fast change of direction the right decision. In these scenarios, I like to take a few minutes to knock up a decision table in Notion. I articulate a few options, the pros and cons of each, and my recommendation. I share it with the team, gather feedback, and document the decision in a decision log once it\u0026#8217;s agreed. Empowering teams to respond effectively to change Embracing change New opportunities will arise. To take advantage of new opportunities fast and at minimum cost, teams should: Delay decisions to the last responsible moment. Avoid making premature decisions. Instead delay commitment and keep important and irreversible decisions open until the cost of not making a decision becomes greater than the cost of making a decision. Respond to change. Embrace change by trying to minimise its cost. Reducing cycle time, queues, work in progress and batch size. Not planning in too much detail too far ahead. Starting discovery close to delivery and including the people who will do delivery in discovery. These are some of the ways we do this. Leaders need to strive to avoid re-prioritising work that has already started, but teams need to recognise that sometimes this is the right decision to make \u0026#8211; either because new information came up, or with the benefit of hindsight, leaders made the wrong decision. Be transparent. Strategies, plans and decisions should be open where everyone can see them. They should be regularly communicated at an appropriate cadence. Even though long term plans change, they are still immensely valuable so we have a sense of where teams are heading and best bets on how to get there. Decision making flow chart for when new things come up Here is a decision making flow diagram that I have shared with my teams to help us make quicker prioritisation decisions. In short: stay focused on strategic must haves and keeping the product operational. Let\u0026#8217;s have a conversation if new opportunities as they arise. Questions I like to ask when prioritising Again with the transparency theme, I like to be open with teams about the questions I like to ask when picking between options. Here are some of my favourite questions to ask when new things come up. Strategic fit Is this a side quest or part of the main mission ? Why do this now rather than 6 months time? Lean thinking How can we deliver 80% of the value of this with 20% of the effort? What’s the MVP (where we do this as fast as possible so that we can fail fast and get value in hands of users early?) Value. The impact this opportunity could have on our organisation or users Impact: is this a game changer? A quality of life improvement? How many users does it impact? How important are those users? Does it help us secure revenue? Is it aligned to our strategy? Confidence: how confident are we that doing this thing will deliver the value? Risk: does it reduce our exposure to risk? Or enable future opportunities? Urgency. Something is urgent if doing it later reduces its value Deadlines (eg. for partners, or big publicity events) A bug that might blow up into something bigger if not fixed A competitor might get there first otherwise Effort. What it will cost us to realise this value How much effort does this take? Effort from who? How risky are the above effort estimates? Conclusion Prioritisation is only effective when grounded in strategy. Frameworks can support good decisions, but they are no substitue for clarity and fast feedback loops. There is huge value in creating alignment, so that teams can move quickly and confidently in the right direction even when things changed. Focus, transparency and flexibility help teams stay focussed on building the right things. ","permalink":"https://alaniswright.com/blog/product-strategy-prioritisation-frameworks-and-responding-to-change/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  Product teams often face more opportunities than they can act on, with new ones arising all the time. This post explores the link between strategy and priorities, when prioritisation frameworks help or hinder, and how to empower teams to make smart, timely decisions as new opportunities emerge.\n\u003c/p\u003e\u003cfigure class=\"wp-block-image size-full\"\u003e\n\u003cp\u003e\u003ca href=\"https://alaniswright.com/wp-content/uploads/2025/08/image-1.png\"\u003e\u003cimg loading=\"lazy\" decoding=\"async\" width=\"878\" height=\"614\" src=\"https://alaniswright.com/wp-content/uploads/2025/08/image-1.png\" alt=\"\" class=\"wp-image-1086\" srcset=\"https://alaniswright.com/wp-content/uploads/2025/08/image-1.png 878w, https://alaniswright.com/wp-content/uploads/2025/08/image-1-300x210.png 300w, https://alaniswright.com/wp-content/uploads/2025/08/image-1-768x537.png 768w, https://alaniswright.com/wp-content/uploads/2025/08/image-1-705x493.png 705w, https://alaniswright.com/wp-content/uploads/2025/08/image-1-450x315.png 450w\" sizes=\"auto, (max-width: 878px) 100vw, 878px\" /\u003e\u003c/a\u003e\u003cfigcaption class=\"wp-element-caption\"\u003e\u003cem\u003eToo true! Image borrowed from \u003ca href=\"https://productmanagermeme.com/product-manager-when-someone-read-their-product-strategy\"\u003eProductManagerMeme\u003c/a\u003e\u003c/em\u003e\u003c/figcaption\u003e\u003c/figure\u003e\u003c/p\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"why-strategy-must-precede-prioritisation\"\u003eWhy strategy must precede prioritisation\u003c/h2\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  Effective prioritisation starts with a clear strategy. Without one, even high-value tasks can pull teams in too many directions, diluting impact and slowing progress.\n\u003c/p\u003e","title":"Product strategy, prioritisation frameworks and responding to change"},{"content":" As a product manager, one of my favourite ways to prioritise problems to solve for users is to understand their Jobs to be Done (JTBD). The best way to get this data is by having conversations with many users, but this is not always something users have time for. Surveys are a great complementary method to gather this data quantitatively and quickly. In this post, I share the thinking behind the Jobs to be Done survey I have been running with users in my current role. What are Jobs to be Done? JTBD is a framework that helps organisations understand user needs by understanding the underlying job they are trying to accomplish. The idea is that the jobs a user needs to get done remain quite similar over time, but the products or services they use to get those jobs done vary.\u0026nbsp; What is a Jobs to be Done survey? A JTBD survey is a quantitative method used to gather data on user needs by assessing both the importance of a job to the users and their satisfaction with existing solutions. Important jobs with low satisfaction are the ones where users are more likely to be open to try using a new product to help them get the job done. A section of my JTBD survey\nWhy I wanted to run a survey The best way to learn about a person\u0026#8217;s JTBD is to talk to them. However, it is not always easy to get busy people to sign up for face to face conversations. I wanted a 3-minute option I could give to users who want to give feedback, but do not want to spend 15-30 minutes on the phone with me. One of the automated follow-up emails I send to users who complete key actions like downloading datasets\nWhy I didn’t like the surveys I found online I wanted this survey to be something a participant could complete in a couple of minutes. I did not want the length of the survey to scare them away. So I started looking at Jobs to be Done survey templates online to borrow some ideas. However, most of the templates I found online had: Many jobs for users to fill in data for Each question takes up a large amount of screen space for the user So I decided to try something different. An example JTBD survey created in Google Forms. Imagine how long this form would get with multiple jobs! Source\nWhat I tried instead 1. Identify an online form tool that supports conditional logic I wanted something that allowed some fields to be shown only if other fields are selected. In my case, I chose Jotform. 2. Identify biggest pain points First, I ask users to pick their biggest pain points from a list. There is a maximum limit of four. This forces the user to prioritise and stops the form from getting too long. The form starts by asking users to select their biggest pain points\n3. Assess biggest pain points only Next, I ask the user to rate how important the task is to their work, and how satisfied they are with their approach to the task. Once a user reaches this point, I already know that these are their biggest pain points. I do not want to risk them abandoning the form, so I have made these fields optional. This is important, as some users skip this section of the form. Perhaps they would not complete the form at all if I force them to complete very field\u0026#8230; This section of the form pops up when the user selects their top tasks\n4. Analyse the results There are two signals of importance: How often the job gets selected as one of the top four tasks What score the user gives the job for importance The satisfaction question helps us understand how they feel about their existing solution. The best tasks to focus on are ones where the user sees the task as important to their work but they have low user satisfaction with the current solution. A good example is the task below. Great example of a job with high importance but low satisfaction – the perfect job to solve for users\nUsing the results to make better decisions I don’t change my strategy based solely on the scores from a JTBD survey. But combining this data with what I am seeing from user research, product analytics, and partner feedback has allowed me to build a more complete and accurate picture of what important jobs our users are struggling with and why. These are the areas where users will be more open to trying new solutions. These are the problems where users might hire my product to help them solve the problem. These are the problems I should focus on solving, assuming, of course, that we can find a sustainable and feasible way of doing so The survey Congratulations for getting to the end! Here is the survey. Go forth and conquer learn about your users. ","permalink":"https://alaniswright.com/blog/jobs-to-be-done-surveys/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  As a product manager, one of my favourite ways to prioritise problems to solve for users is to understand their Jobs to be Done (JTBD). The best way to get this data is by having conversations with many users, but this is not always something users have time for. Surveys are a great complementary method to gather this data quantitatively and quickly. In this post, I share the thinking behind the Jobs to be Done survey I have been running with users in my current role.\n\u003c/p\u003e","title":"JTBD / Jobs to be Done – survey and template"},{"content":" I have been using tools like ChatGPT more and more in my work. A key part of learning how to use these tools well is learning how to write good prompts \u0026#8211; also known as prompt engineering.\u0026nbsp; This post covers why I think prompt engineering is an important long-term skill for everyone to learn and some of the techniques that work for me in my product management work. ChatGPT’s cartoon representation of me giving clear instructions to an AI so that it knows what I want (aka prompt engineering)\nPrompt engineering as a long-term skill to build When I first heard people talking about prompting being an important skill to learn, I was skeptical. I remember how being good at writing Google search queries used to be an important skill. And I remember how Google got better at giving good responses to even the laziest and most general user queries. However, finding 10 blue links on the internet that relate to a thing is fundamentally different to the types of jobs we expect LLMs to perform. Traditional Google search helps you find the information you need to do the job. LLMs go further \u0026#8211; finding, synthesising and summarising information. LLMs are rapidly proving themselves capable of doing tasks and jobs that felt like science fiction only a few years ago. Someone told me a couple of years ago that AI is like having unlimited interns available to do your bidding. As the models have become more advanced, it is perhaps more like having a thousand experts. I have spent much of the past 15 years managing product and project work with teams of interns, experts and everyone in-between.\u0026nbsp; Clearly communicating the work you want to get done is a timeless management skill. Having your intent understood is fundamental to a job being done well. Until AI tools can read our minds, I believe this will remain a key skill for working with LLMs, like it is now when working with people. Engineering? On a lighter note, I do find it kind of surprising that the industry name for writing effective natural language prompts has the word \u0026#8220;engineering\u0026#8221; in it. If you fancy a chuckle, I suggest Googling prompt engineering memes. One of my favourites is below. Prompt engineers vs AI engineers\nHealth warning Even with the best prompts, AI tools as of 2025 can make mistakes, provide inconsistent results and not follow instructions. This is due to the probabilistic nature of LLM models. I approach AI generated content with cautious optimism. Here are some personal ground rules: I never use the outputs from an AI tool without checking them over myself first.\u0026nbsp; More often than not I don’t copy and paste out of AI, preferring instead to pick out the best ideas manually and integrate them with my work. I think by writing. So if I give away too much of the writing, I give away too much of the thinking too.\u0026nbsp; ChatGPT is an excellent thought partner, sounding board, idea generator and critic.\u0026nbsp; But I retain agency over what I produce. Before sharing AI generated content with people, I almost always edit it into my own style. When someone sends me something that looks like it has been written by ChatGPT, I have found myself instinctively less trusting of it.\u0026nbsp; I know I am not alone in this thinking.\u0026nbsp; Increasingly, something not looking like it has been written by AI is key to getting humans to pay attention to it. When I share unedited AI generated content with people, I clearly label it as AI generated.\u0026nbsp; It is important that readers of the content understand that it was made by AI, so that they can have a sense of its limitations. This is particularly important when sharing content that I lack domain expertise in, as my ability to detect inaccuracies is lower. Writing good prompts 1. Role Telling an AI tool to play a specific role primes it to use styles and domain knowledge associated with that role. LLMs are trained on almost everything humans have ever written. Specifying a role encourages it to come at the problem from a more specific angle. When I am at work, I often tell ChatGPT to “act like an expert product manager with domain experience in climate policy and NLP”. This works because product management is what I do, and climate policy and natural language processing are the domains most relevant to my product. 2. Context When LLMs answer questions, they do so based on what they already know about the world from their training, and the context provided in the prompt. As a product manager, a big part of my role is making sure teams understand the context. A team that understands the product vision, strategy and problems to solve will deliver much more effective solutions than a team that is just given tasks to do. The same goes for LLMs. When I ask an LLM to help me generate some product ideas, it does so in a very general way. When I give it my product strategy as context, it generates ideas that are more aligned with my strategy.\u0026nbsp; This context is remembered in the chats that follow. It is important to be aware of how much an AI can remember in a conversation before it forgets earlier parts.\u0026nbsp; This is known as the context window. Every bit of information in a chat adds up: user prompts, AI responses, the content of links and attachments in chat.\u0026nbsp; More content leads to more storage being used. For API users it also leads to more cost.\u0026nbsp; Most AI models have a limit to the amount of storage space available for context. As this limit is hit, old context is lost. This is less of an issue now as models have quite large context windows. ChatGPT4o has a context window of 128k tokens (~100k words, \u003e40x the length of this post). I don’t hit that limit very often, but in very long chats where I am bouncing a lot of ideas around with the AI tool, I might reshare my original context to reduce the risk that important details are overlooked. 3. Formatting the output When responding, AI tools will format the response in the way it thinks we are most likely to understand it. But people are different. We all like to receive information in different ways. And different organisations have different standards and conventions for how certain documents are written.\u0026nbsp; So when prompting, it often makes sense to define the format of the response. For product comparisons or decisions between things, I like to see information in a table with columns as options, rows as criteria, and scores to indicate how aligned options are with different criteria. For drafting requirements docs or summarising meetings, we have a standard format we try to use in my organisation, so I tend to use those. Another technique I like to use is “Explain this like I’m an 11 year old”. Or if I’m feeling particularly out of my depth “Explain this to me like I’m a 5 year old”. As a generalist, I often have to learn new technologies and domains fast, and this can help when I am struggling with more complex content. 4. Formatting the prompt Would you rather read a block of text? Or something that was neatly formatted with headings, bullet points and lists? Documents are easier for humans to read when they are formatted. The same is true for AI. I do a lot of my writing in Obsidian \u0026#8211; a markdown based knowledge management tool. Markdown is a lightweight markup language for creating formatted text using a plain-text editor.\u0026nbsp; In English, that means it is a simple way to style text using symbols, like # for headings or \u0026#8211; for bullet points.\u0026nbsp; Markdown is easy for humans to read. Copying and pasting into ChatGPT from Obsidian preserves the markdown syntax. That makes it easy for AI to read too. I use ## (heading 2) tags to explain the structure of my prompt: role, task, output format and context are my go-to headings. I use ### (heading 3) tags to break down each of those further if needed. This is very useful when I share my product strategy as context. 5. Examples If I ask you to recommend a movie or series for me, what would you recommend? What about if I tell you I like Star Wars? What about if I tell you that I like Star Wars, West Wing and Game of Thrones?\u0026nbsp; The more examples you have of things I like, the more likely you are to recommend something that I also like. The same goes for writing product requirements. Writing good requirements is often enough for engineers to understand what they need to build. Giving some specific examples of those requirements in action (i.e. test cases) often helps clarify things and remove room for ambiguity. Now I am going to try to impress the data scientists at work by using some complex words for things. Zero shot prompting is where you provide no examples. One shot prompting is where you provide one. Few shot prompting is where you provide multiple. A paper written in 2020 titled “Language Models are Few-Shot Learners” found that language models get more accurate the more examples you give them.\u0026nbsp;\u0026nbsp; Image copied from Language Models are Few-Shot Learners\nThat was five years ago. A lot has happened in the past 5 years in the world of generative AI, and powerful AI models are getting better at providing accurate answers without any examples. But if I was hiring a kitchen designer, I would start by showing them examples of other kitchens that I like. So intuitively, giving an AI some examples of what good (or bad) looks like feels like it can only help. The main risk with giving examples is prematurely constraining the AI’s thinking. So for idea generation with AI, it makes sense to generate at least some ideas in a zero shot way. 6. Breaking down work If I am building a product, I don’t do it all in one go. I start with the most important problems I am trying to solve, test the riskiest assumptions and prioritise the most high impact features. I break work down into stages: discovery, ideation, prototyping, building, testing and learning.\u0026nbsp; I tackle things step by step.\u0026nbsp; The same is true for most other types of problems people solve. And the same is true for working with AI. Prompting AI tools to think step-by-step has demonstrably increased ChatGPT\u0026#8217;s accuracy at solving complex logical problems. Showing how it got to a conclusion also has the added benefit of making results easier for humans to interpret.\u0026nbsp; I am not sure how important it is to use phrases like “think step-by-step” in prompts anymore, as I think newer models might be doing it by default.\u0026nbsp;\u0026nbsp; Another way to break down work is to ask an AI to start by explaining how to go about solving a problem. And then ask it to follow those instructions in sequential prompts. Breaking work up into separate prompts reduces cognitive load by allowing the AI to focus on doing one task at a time and doing it well. It also makes it easier for me, the prompter, to intervene at each step and make sure that it is done to the right standard before moving on to the next one. Most of my experimentation with AI tools has been within the official ChatGPT app. I have only spent a little bit of time using the ChatGPT API and trying to build my own workflows, connecting together different prompts with the output from one an input into another. This is something I am playing around with at the moment, but I have not had any real success with it yet to support me in my product management work. If you have, and you fancy getting in touch for a chat, then reach out. 7. Prompting for prompting This is one of my favourite prompts: Act like an expert prompt engineer. Assist me to turn this prompt into a better prompt using . Prompts like these have helped me learn about ways to improve my prompt. Starting conversations like this can help set the AI tool up to give a better answer the first time around.\u0026nbsp; I am sure that genuine experts out there will be able to write better prompts than AIs are capable of. But for someone like me, this is an effective and low effort way to quickly make prompts better.\u0026nbsp; I also know that there are lots of other people asking questions like these. All that evaluation data means AI tools are likely to give relatively good answers to this type of question.\u0026nbsp; 8. Critical friend One of the best uses of AI tools is as a thought partner and critical friend. I like to use it to generate and explore ideas.\u0026nbsp; But sometimes I get the feeling it is being a little bit too nice. The pessimistic Brit within me can get a bit tired with the overly positive tone of AI tooling. OpenAI recently acknowledged their April update made this problem worse in ChatGPT.\u0026nbsp; The CPO of Anthropic (maker of Claude) likes to tell Claude “Be brutal, Claude, roast me.” He notes it is hard to get Claude to be too brutal, but this gives a marked improvement over prompts like \u0026#8220;What could be better with this work?\u0026#8221;. I can confirm from trying it out on this blog post that “Be brutal. Roast me.” is a very effective prompt! ChatGPT roasting this blog post\nMy response to the above roasting: Disagree. Plenty of structure in this bad boy. Look at those headings and numbered subheadings! Your rules about blog post length do not concern me. I prefer long-form content, and I have had one or two compliments about my blog posts over the years I think you might have been overfitted on American training data 😉 Here is what your buddy Gemini told me: “British humility, while not a universal trait, often manifests as self-deprecation and a preference for understatement” I am not trying to be a thought leader or entertain thought leaders. I write primarily because writing helps me understand my own thoughts. Writing publicly forces me to raise the bar, and hopefully entertains a few people in the process Example prompt I used recently to think through product ideas Here is a prompt I used recently that uses some of the techniques listed above. I followed it up with more specific questions about different parts of the AI response. The end product was an opportunity solution tree in Whimsical (like Miro, except cheaper). I used this mainly to explore ideas, and didn’t end up copying and pasting anything more than a few words here and there into the final document I shared with the team. ## Role: Act as a senior product manager at Climate Policy Radar, with domain expertise in climate policy and NLP. Based on the product strategy below, complete the following task: ## Task: Create an Opportunity Solution Tree using the methodology from Teresa Torres described at: https://www.producttalk.org/2023/12/opportunity-solution-trees/?srsltid=AfmBOop4oYGkXYEUVhzoDj_2EvQ7eZ_Vr4W53ZwRwj6Vdyem1yu8Jxw9 The top level outcome is \u0026#8220;Users can find and select the the result(s) most relevant to their search intent\u0026#8221; ## Output format: List the opportunities in a list and the solutions as sub items. Follow the style guide for writing opportunities and solutions described above ## Product strategy: ## Context:\nOther AI blog posts written by me Google AI Pro: Image Editing, Deep Research and Fantasy Premier League 6 ways I like to use ChatGPT AI product management in high stakes domains 8 ways I am using AI to help me be a better product manager (and 4 ways I am not) ","permalink":"https://alaniswright.com/blog/prompt-engineering-as-a-product-manager/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  I have been using tools like ChatGPT more and more in my work. A key part of learning how to use these tools well is learning how to write good prompts \u0026#8211; also known as prompt engineering.\u0026nbsp; This post covers why I think prompt engineering is an important long-term skill for everyone to learn and some of the techniques that work for me in my product management work.\n\u003c/p\u003e\u003cfigure class=\"wp-block-image size-large\"\u003e\n\u003cp\u003e\u003ca href=\"https://alaniswright.com/wp-content/uploads/2025/06/image.png\"\u003e\u003cimg loading=\"lazy\" decoding=\"async\" width=\"1030\" height=\"687\" src=\"https://alaniswright.com/wp-content/uploads/2025/06/image-1030x687.png\" alt=\"\" class=\"wp-image-1038\" srcset=\"https://alaniswright.com/wp-content/uploads/2025/06/image-1030x687.png 1030w, https://alaniswright.com/wp-content/uploads/2025/06/image-300x200.png 300w, https://alaniswright.com/wp-content/uploads/2025/06/image-768x512.png 768w, https://alaniswright.com/wp-content/uploads/2025/06/image-1500x1000.png 1500w, https://alaniswright.com/wp-content/uploads/2025/06/image-705x470.png 705w, https://alaniswright.com/wp-content/uploads/2025/06/image-450x300.png 450w, https://alaniswright.com/wp-content/uploads/2025/06/image.png 1536w\" sizes=\"auto, (max-width: 1030px) 100vw, 1030px\" /\u003e\u003c/a\u003e\u003cfigcaption class=\"wp-element-caption\"\u003e\u003cem\u003eChatGPT’s cartoon representation of me giving clear instructions to an AI so that it knows what I want (aka prompt engineering)\u003c/em\u003e\u003c/figcaption\u003e\u003c/figure\u003e\u003c/p\u003e","title":"AI prompt engineering as a product manager"},{"content":" I have been a ChatGPT Plus subscriber for about 6 months now. To celebrate, I wrote a blog post about 6 ways I am using it to help me get things done in life and at work. 1. Coding assistant “Look after the pennies and the pounds will look after themselves” is one of my favourite mottos. I am the type of guy who signs up for new current accounts to get introductory bonuses, and watches two seasons of 1923 in 6 days to avoid any fees beyond the one week free trial. So, it should not come as too much of a surprise that the idea of paying £20 per month for more than one AI assistant really grates on me. I am what you might call a vibe coder. I occasionally do some data analysis in Python for work, but most of my exposure to coding comes from hobby projects I do in my own time.\u0026nbsp; Using Cursor, I frequently find myself running out of free credits. After which point, the tool slows down so much that it becomes unusable.\u0026nbsp; I recently switched to VS Code, because I heard about Gemini Code Assist being free for personal projects, but not available on Cursor. However, at some point in my VS Code journey, I pasted a bit of code into my ChatGPT desktop app to ask it for help, and I realised that ChatGPT was able to read from the file. Upon further investigation, I realised that there is an integration that enables the desktop ChatGPT app to read open files in VS Code. So I paste error messages or questions into ChatGPT, and use that to help me get over problems. This is not as fully featured as Cursor or Copilot. But for a hobbyist like me, it does the job. As someone learning to code, it is kind of helpful to use a tool which does not edit my code directly. It encourages me to figure things out for myself that bit more. And models available on ChatGPT Plus perform better on coding tasks than the free LLM (large language model, another name for the type of model ChatGPT is) options that users fall back on when they run out of free credits. 2. Image editor and creator Since I moved house a few months ago, I have spent a lot of time deciding what I want it to look like and trying to explain my vision to builders. My graphic design skills are not what they used to be. Online visualisation tools from suppliers are pretty limited. So whilst everyone else was creating photos of themselves in the style of Spirited Away, I was using ChatGPT’s image editing functionality to help me figure out how to design my house. Here is an image of my future kitchen generated by my kitchen designer at Howdens.\u0026nbsp; I wanted to try out some different tile combinations on the walls. The tool the Howdens designer was using would not let her edit the walls. The below was the best I could get out of the Topps Tiles visualiser. The best I could do in the Topps Tiles visualiser\nI tried out lots of tile colours and sizes, but eventually settled on this design. Getting the tiles to go full height on the back wall, two tiles high on the side wall, and up the sides of the peninsula took a little bit of prompting to achieve. But this is way more advanced than what other online tools were able to achieve, and a lot cheaper/quicker than working with a professional designer.\u0026nbsp; ChatGPT’s version of my kitchen\nHigh fidelity visualisations like this one have helped me make big design decisions with confidence that the end product will look as good as it looks in my imagination. It is also helped me to minimise room for misunderstandings with my builder. I am a big user of the ChatGPT app on Mac. But I recently discovered the browser version allows you to specify which parts of images need editing via the UI. This can be handy when ChatGPT decides to change things you don’t want it to (which it often does, even with this feature). House designs aside, other use cases include: Checking if my tattoo ideas will look good on me (answer: no they don’t. Glad I figured that out before putting needle to skin) Creating visualisations for work presentations and blog posts\u0026nbsp; Explaining to suppliers on Etsy what I want a customised product to look like Imagining what our future family might look like (answer: her hair \u0026 eye colour unsurprisingly dominate mine, but the most surprising thing seems to be how parenthood has changed our faces and made me shorter) Prompt: Create a realistic image of a family. The two people in the photo as parents. With their 2 children – boy and girl. Blend features from both parents.\nUpdate: check out my October 2025 post on image editing with Google AI Pro for a more recent take on image editing 3. Real-time meeting assistant There is a wealth of good information on the internet in places like Stack Overflow and Reddit.\u0026nbsp; But usually these resources aim to answer a question similar to mine, rather than the exact question I am asking. As a product manager in a startup, I often find myself trying to follow along in very technical conversations. Examples include meetings with legal experts about law \u0026 policy taxonomy or workshops with the engineering team planning a new API. Trying to Google these topics as I go through meetings can get me to the information I am looking for too slow, and lead to me getting lost in the conversation. I am not afraid to put my hand up and ask stupid questions, but it is nice not to have to do that too often. One thing I have been doing more recently is kicking off a ChatGPT conversation when I know things are getting too technical for me. I start by explaining the type of conversation I am having, and asking it to provide quick, simple answers for me to answer my questions when I have them. I can get fast answers to questions like “what is model context protocol” and “if I use a custom font, what percentage of users might have to see fallback fonts by channel”. I can learn in real time, keep up with the conversation and make a meaningful contribution to the meeting. 4. Teacher Teaching in general is an area in which I think LLMs excel. If I read a line in a book that I don’t understand, I like to paste that content into ChatGPT and ask it to explain. More often than not, after a few exchanges, it can help me figure out what the author was trying to say. As a product manager, the only words I say at work more often than “Not yet” are “What I heard you say was”. Playing back your understanding to others is one of the best ways to ensure two people understand each other. Speaking or writing things in my own words is how I learn things. It is a big part of why I keep this blog going. So I often like to try to explain things to ChatGPT and see how it picks apart my explanations. This helps me cement my learning and saves my team from having to listen to me speak quite so much. 5. Product comparer Moving house means that I often have to choose between products in domains that I really do not understand. In years gone by, I would have done this by reading comparisons that other people have written. However, you need to read a lot of sources to mitigate the risk of being over-influenced by a reviewer who is trying to sell you something. I also often find myself with weirdly specific criteria that other people haven’t included in their reviews. Things like “patio tiles which don’t stain when cats are sick on them”. Some comparisons I have done recently include: How good are Rehau vs Liniar windows Compare Labradors and Golden Retrievers. Which are smaller and easier to train Compare composite front door from Endurance and DirectDoors. Give each a rating for quality, security, and durability\u0026nbsp; Best earbuds for phone calls (I am struggling to find earbuds where my parents won’t complain about the background noise on calls!) As most LLMs are trained on the content of the internet and can repeat patterns found in bodies of text, I think these are the types of questions that they are naturally suited to. The answers given should be a quick aggregation of the type of content that exists on the internet about this topic, which is good enough for me.\u0026nbsp; I am a big fan of asking ChatGPT to respond with the answer in a table format, defining the rows and columns I want it to include, and asking it to score things out of 10. This is the way I like to consume information. Being able to get most content into that format is super helpful. For high-stakes decisions, I don’t rely on ChatGPT alone and seek advice from a person who knows what they are talking about.\u0026nbsp; But it does give me the information I need to participate in the conversation. 6. Cost estimator A friend is buying his first home and wanted to make an offer on a property. He asked me for my thoughts on how much he should offer. So, rather than scouring sale history on Zoopla and checking out what the neighbourhood was like on Google Street View, I uploaded the advert of the property and asked it to estimate the true market value.\u0026nbsp;\u0026nbsp; ChatGPT came back with all sorts of data on recent price trends in the area and average prices of homes like that one, and sought to give an estimate factoring in lots of the nuances about this particular property (e.g. planning permission granted for expansion).\u0026nbsp; The estimated market value it came back with gave us a good idea of the ballpark price to aim for, but all the assumptions it made when giving the estimate gave us useful information to go on.\u0026nbsp; That said, he was outbid on this property. Perhaps the eventual buyer did not have the benefit of ChatGPTs wisdom on the matter! I have had more success in getting ChatGPT’s help to estimate other work. For example, it was spot on with its estimates of the relative cost of replacing a traditional boiler like for like vs with a combi boiler vs a combi boiler and immersion heater. It was also very accurate in estimating the costs of laminate vs LVT flooring, painting rooms and the labour cost for installing different types of tiles.\u0026nbsp; When I have got high costs back from suppliers, it has helped me figure out when to keep shopping around vs when to recognise that I have a good deal.\u0026nbsp; Final thoughts ChatGPT is not the best tool for every task. Claude is the best for coding, and Perplexity is a joy to use for web search. However, none of the alternatives do all the things that ChatGPT does.\u0026nbsp;\u0026nbsp; Personally, there is huge value in having all my LLM chats in one place. I frequently find myself using the search bar in ChatGPT as a way of finding useful information from previous conversations. Not having this data fragmented across different LLMs is useful. And it is great for OpenAI too, as whilst they might be losing money on my account right now, the barriers for me personally to switch away from them are increasing all the time. And as the cost of LLMs continues to come down exponentially year by year, there is huge value in being the platform where users go with their questions about things. Ask Google! So, as someone who does not want to pay for more than one AI product and likes the convenience of having a one-stop shop, it seems like the obvious choice for me right now. Other AI blog posts written by me Google AI Pro: Image Editing, Deep Research and Fantasy Premier League AI prompt engineering as a product manager AI product management in high stakes domains 8 ways I am using AI to help me be a better product manager (and 4 ways I am not) ","permalink":"https://alaniswright.com/blog/6-ways-i-like-to-use-chatgpt/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  I have been a ChatGPT Plus subscriber for about 6 months now. To celebrate, I wrote a blog post about 6 ways I am using it to help me get things done in life and at work.\n\u003c/p\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"1-coding-assistant\"\u003e1. Coding assistant\u003c/h2\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  “Look after the pennies and the pounds will look after themselves” is one of my favourite mottos. I am the type of guy who signs up for new current accounts to get introductory bonuses, and watches two seasons of 1923 in 6 days to avoid any fees beyond the one week free trial. So, it should not come as too much of a surprise that the idea of paying £20 per month for more than one AI assistant really grates on me. \n\u003c/p\u003e","title":"6 ways I like to use ChatGPT"},{"content":" In 2021, I wrote a blog post on running effective show \u0026 tells. If I were writing that blog post again today, the first thing I would add would be kick off the event with trumpet time. Trumpet time. How we kick off our weekly team show \u0026amp; tells at Climate Policy Radar\nWhat is trumpet time? A chance to celebrate the achievements and contributions of your team over the past week. This was something our CEO introduced at Climate Policy Radar last year, and it is how we kick off all of our weekly show \u0026 tells. What problem is it solving? There are lots of small wins that happen throughout the week, which don’t always get spoken about.\u0026nbsp; Giving and receiving deserved compliments is a nice habit to get into, and helps build a happier and healthier team. But as with most habits that would be good to get into, most people are not in the habit of doing them as much as they should.\u0026nbsp; When we were just 11 people, we solved this problem through regular retrospectives. As our organisation scaled beyond the size where doing retrospectives together was feasible to do regularly, we lost a broad forum to recognise each other\u0026#8217;s positive contributions at an organisational level.\u0026nbsp; How does trumpet time help? Habits stick much more easily when you turn them into a routine that happens at the same time and place every week. They also stick better when you do them as part of a group.\u0026nbsp; So that’s exactly what we have done with trumpet time.\u0026nbsp; We take the first 5 minutes of our weekly show \u0026 tell to recognise each other’s contributions throughout the week.\u0026nbsp; We do trumpet time asynchronously in Slack. This works well for a few reasons:\n1. In an hour meeting where people speak and listen, 5 minutes of solo focus time to think and write gives some nice variety 2. Many people find it easier to write a Slack post than to say something out loud in front of a group of people 3. As a team of 30, in 5 minutes, each person can easily add 5 comments and browse through the comments from the rest of the team. If we did this verbally, there is no way that much could be shared in such a short space of time 4. Everyone can bring their best emoji game to respond to what others are saying How does it work? Step 1: Announce the start of trumpet time in the team Slack channel\nTrumpet emojis and GIFs get a lot of love here Step 2: Start the tunes.\u0026nbsp; My colleague Sion has mastered the art of playing his Spotify over Slack. He has a great selection of… can you guess it? Trumpet-themed tunes. My favourites are the ska-punk ones. Step 3: Everybody starts commenting We all spend a few minutes adding some comments. I like to jog my memory by flicking through my to-do list and calendar.\u0026nbsp; The types of things I like to say include: Thanking people whom I have worked with closely throughout the week Calling out positive feedback I have had from a user interview or partner conversation Recognising people who are slogging through particularly hard but invisible pieces of work. Or things that won’t otherwise get shown off in a show \u0026 tell Calling out new product improvements or research findings. Usually, this means cross-posting something that has been covered more thoroughly in a different channel\u0026nbsp; Giving out made-up awards like “engineer of the week” or “data scientist of the week”. This has turned into a bit of a running joke with some making the case throughout the week that perhaps a bit of work they’ve done might earn them the coveted top spot General office banter. There are often a lot of funny comments Step 4: Read and reach (with emojis) Once I’ve finished commenting, I read through the posts. I also take time to admire the excellent emoji game from the wider team. If I am feeling generous, I might dish out some of my go-to emojis on my favourite posts. Usually the ones mentioning me 😉 Step 5: Wrap up The music stops. The facilitator brings trumpet time to a close. And we move on to the rest of our show \u0026 tell agenda Final word Trumpet time works well for us. I think it is a great way to kick off regular team meetings. In particular, I recommend it for organisations that have grown beyond the size where they can do a regular team retrospective, and for those who do their meetings remotely. ","permalink":"https://alaniswright.com/blog/trumpet-time/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  In 2021, I wrote a blog post on \u003ca href=\"https://alaniswright.com/blog/running-effective-show-tells/\"\u003erunning effective show \u0026 tells\u003c/a\u003e. If I were writing that blog post again today, the first thing I would add would be kick off the event with trumpet time. \n\u003c/p\u003e\u003cfigure class=\"wp-block-image size-large\"\u003e\n\u003cp\u003e\u003ca href=\"https://alaniswright.com/wp-content/uploads/2025/04/trumpet-time.png\"\u003e\u003cimg loading=\"lazy\" decoding=\"async\" width=\"1030\" height=\"687\" src=\"https://alaniswright.com/wp-content/uploads/2025/04/trumpet-time-1030x687.png\" alt=\"\" class=\"wp-image-1010\" srcset=\"https://alaniswright.com/wp-content/uploads/2025/04/trumpet-time-1030x687.png 1030w, https://alaniswright.com/wp-content/uploads/2025/04/trumpet-time-300x200.png 300w, https://alaniswright.com/wp-content/uploads/2025/04/trumpet-time-768x512.png 768w, https://alaniswright.com/wp-content/uploads/2025/04/trumpet-time-1500x1000.png 1500w, https://alaniswright.com/wp-content/uploads/2025/04/trumpet-time-705x470.png 705w, https://alaniswright.com/wp-content/uploads/2025/04/trumpet-time-450x300.png 450w, https://alaniswright.com/wp-content/uploads/2025/04/trumpet-time.png 1536w\" sizes=\"auto, (max-width: 1030px) 100vw, 1030px\" /\u003e\u003c/a\u003e\u003cfigcaption class=\"wp-element-caption\"\u003e\u003cem\u003eTrumpet time. How we kick off our weekly team show \u0026amp; tells at \u003ca href=\"https://www.climatepolicyradar.org/\"\u003eClimate Policy Radar\u003c/a\u003e\u003c/em\u003e\u003c/figcaption\u003e\u003c/figure\u003e\u003c/p\u003e","title":"Trumpet time: a great way to kick off a remote-first all-team meeting"},{"content":" Design sprints are a technique used by teams to ideate, prototype and test product ideas in 5 days.\u0026nbsp; I have been involved in a few of these over the years, and I have always found myself getting the most value out of the sketching part.\u0026nbsp; So much so that I have started running sketching workshops independently of design sprints with my teams. This post explains how design sprints work and why I find the sketching part to be so useful. It also includes a plan for a 90-minute sketching workshop called crazy 8s that I like to run with teams to generate new ideas. AI generated image of a team sketching to ideate digital product ideas. Not bad!\nMore about design sprints Design sprints were popularised by Google, and immortalised in Jake Knapp’s book Sprint. The 5-step process involves: Understanding the user and the problem Sketching solution ideas Deciding which solution to test Prototyping the solution Validating with users ChatGPT’s attempt to draw the design sprint process. AI isn’t threatening illustrators for a while yet!\nI have found design sprints to be particularly useful for teams: with lots of people who can’t usually work together (e.g. people from a different organisation or team) who don’t usually get a chance to focus on one thing at a time, and need time to focus on solving a hard problem\u0026nbsp; who want to kick-start their momentum after a period of slow delivery, and get into good habits of delivering faster In the book, a design sprint lasts 5 days, but 5 days is a long time in tech.\u0026nbsp; Most of the sprints I have been involved in have tried to do it in less time than this.\u0026nbsp; There are lots of examples of people trying to do design sprints in 3 days, 2 days or 1 day. Why I like sketching for ideation I do not like sketching because I am good at art. When I was in school, a friend who was disappointed by one of his paintings did not want to take one of his artworks home. So I wrote my name on it and gave it to my Mum, who framed it and put it up on the wall. Years later, I had become a punk rocker. That mate was over for band practice. He saw his painting on the wall. And I had to admit to my Mum that my greatest artistic achievement was a fraud. She saw the funny side of it. Anyway, I am about as good at sketching as I am at painting. Which is not very good. If you still doubt that statement, read on to see some examples of my art. There is no need for sketches to be a work of art!\nI like sketching because it is accessible, creative, fast and fun. Accessible: I have never met anyone who cannot sketch well enough to have someone else understand what they are trying to draw during a design sprint Boxes, squiggles and the occasional word or two on the page are almost always enough to get the point across. If not, everyone always gets a chance to explain what they were thinking when presenting their idea Creative: sketching unlocks different ways of thinking than those we usually use when communicating in words alone. When people sketch ideas independently and then bring those ideas back to the group, a diverse range of ideas gets generated. I always come away from these sessions with fresh ideas, including new takes on old solutions or brand-new ideas that had not occurred to me before. Fast: visuals are processed faster than words. With less room for confusion. An hour of ideation will develop more and better ideas with sketching than with writing Fun: these are fun sessions to facilitate and participate in. Groups of professional adults don’t often stand around and draw things for each other. There is always a lot of laughter in the room, and some nice visuals to put up on the wall at the end. Non-product managers/designers do not always get as involved in ideating solutions as they would like to. I have found that they in particular come away from these sessions feeling positive and energised.\u0026nbsp; Part of the reason I find sketching the most valuable part is that I usually work in long-lasting cross-functional teams who have a long history of working on a domain together. We already have a good understanding of our users, the problems they face, and strategically, which problems our product is aimed at helping them to solve better. So taking a day out to build a shared understanding feels like overkill. Deciding, prototyping and validating are all things we need to do. But we don’t need to pick one idea to prototype, and then test it the next day with 5 users in a usability test. We usually find that it is possible to prototype more than one idea in a week. And more often than not, the best methods to validate ideas do not involve testing a prototype with 5 users. They involve making small changes to our core product, and seeing how real users react to that over the coming weeks. I am not saying there isn’t value in doing proper design sprints. I am just saying that the sketching part is the bit I tend\u0026nbsp;to get the most value from. So recently, I have run a few ~90 minute workshops with teams where we just focus on sketching, ideating and a tiny bit of prioritising. Proof that I am not good at sketching. Here is something I drew during an ideation session last year\nCrazy 8’s – a 60-90 minute sketching \u0026amp; ideation workshop Below is an agenda for a 60-90 minute sketching workshop I like to run. It is called crazy 8\u0026#8216;s \u0026#8211; presumably because each person has 8 boxes to sketch in. This is best run: Including the people on the team who will design/deliver the work (can also include some people who aren’t full-time members of the team or are external) Close to when the team will have capacity to do something about the ideas (no sense spending time adding items to the backlog which you have no plans to do anything about) You will need: Large sheets of paper folded in half 3 times (to create 8 boxes on the page) Pens Recap of problem (15 mins) Recap the problem you are trying to solve / the opportunity you are trying to exploit Recap of the users you are doing it for Spend WAY more time on this if you plan to ideate in a problem area that is not well known to the team Warmup (5 mins) Pair up. In 30 seconds, draw the person opposite to you without looking at your pen or paper. Everyone holds up their drawings\u0026nbsp; Great little exercise to get everybody to stop worrying about the quality of their drawing! Credit to Conor Delahunty for this idea Sketching (15 mins) Give everybody 15 minutes to sketch out as many ideas as they can Some people suggest keeping this section to one minute per sketch, but I prefer to give people a little longer Lightning demos (1-2 mins per person) Each person shares their sketches and briefly explains their ideas Dot voting (5 mins) People draw dots on the sketches to indicate what they think are the ideas we should progress with. Or their favourite sketch from each person. Dots on each picture are added up (optional) add any questions as post-its on each other\u0026#8217;s sketches Discussion (rest of workshop) Walk through the top voted items in turn having a brief discussion about why they are good, how to develop them further Do this until you run out of time Alternatively After dot voting or discussion, do another round of sketching, to allow people to build on the ideas of others. Lots of good ideas often come this way! However, doing a second round will probably require more than 90 minutes Output A wide variety of ideas from the team A sense of which ideas the team think are worth pursuing ","permalink":"https://alaniswright.com/blog/sketching-for-ideation/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  Design sprints are a technique used by teams to ideate, prototype and test product ideas in 5 days.\u0026nbsp; I have been involved in a few of these over the years, and I have always found myself getting the most value out of the sketching part.\u0026nbsp; So much so that I have started running sketching workshops independently of design sprints with my teams. This post explains how design sprints work and why I find the sketching part to be so useful. It also includes a plan for a 90-minute sketching workshop called crazy 8s that I like to run with teams to generate new ideas.\n\u003c/p\u003e","title":"Sketching to generate ideas with product teams"},{"content":" Buying a house is apparently one of the most stressful things you\u0026#8217;ll ever do. You have to make lots of big and expensive decisions. Going through the process for the 3rd time this last few months got me thinking about the cognitive biases involved in the house buying process. Naturally I then started comparing them to the types of decisions I have to make as a product manager (because that\u0026#8217;s the type of guy I am). Which then naturally led to a blog post. Naturally. In my recent post about my favourite digital tools for house buying, I proclaimed that I had found my forever home, and would never be using Rightmove or Zoopla again. Three days later, something came up in the survey, and the purchase collapsed. This story has a happy ending: I ended up finding a different house which is better in many ways. But to avoid any repercussions from angering the Gods, and because moving house is actually quite a lot of hard work, I have delayed the publishing of this post until well after the move date. Cognitive Bias in House Buying \u0026amp; Selling Cognitive dissonance You know that horrible feeling you get when someone says something that challenges one of your strongly held beliefs? That is exactly how I felt when my Dad pointed out that my lovely brick built house was actually made of timber on the inside. I have almost 40 years of experience (yes, I am nearly that old now) in ignoring my Dad\u0026#8217;s advice and learning lessons the hard way, so I did try hard to take him seriously. There\u0026#8217;s also that nursery rhyme about the three little pigs, and the one with a house made of wood gets eaten by a wolf and the one with a house made of brick survives. But I really did love this house! So off I went on a journey of evidence based research to discover the objective truth about whether this was an issue or not. The estate agent tried to tell me that there was no difference in price between brick and timber houses, despite what I had learnt from nursery rhymes. Image source\nConfirmation bias Confirmation bias is the tendency to look for information that confirms your beliefs. Over the course of 24 hours, I spoke to insurers, estate agents, lenders, architects and timber-frame housing repair specialists. About two thirds of the people I spoke to said it was not an issue, and that I should go ahead as planned. These are the types of people whose opinions I enjoyed listening to! The more sceptical third warned me away \u0026#8211; triggering that not so lovely feeling of cognitive dissonance all over again. Sunk cost fallacy The sunk cost fallacy is the tendency to continue an activity because of the time, money or effort already invested into it. Fortunately I had not spent too much money on this house (largely thanks to Juno\u0026#8217;s second chance guarantee. Thanks again Juno! Best conveyancer ever). But I was 6 weeks into the process and was emotionally invested. I had a vision of living in this house and had started planning my renovations and extensions. However, it makes little sense to factor historical costs in to future decisions. The past is the past, and what matters is that we make the best decisions we can with the information we have now, based on the future cost/benefit. Bandwagon effect Bandwagon effect is the tendency to believe things because other people do. I looked around at other similar properties in the area. There were not many of them that had been sold in recent years, but 1 or 2 had recently sold for good prices. My inclination was to believe that if others had paid a decent price, then I should feel safe to pay a decent price too. However, there was good reason to believe that those buyers might have been blissfully unaware of the stigma associated with that house type, and not had the benefit of a know-it-all father to enlighten them that there might be a problem. It is also likely that buyers hadn\u0026#8217;t known about the construction method when they bought the property. Apparently only 16% of house purchasers get property surveys done at all. Given that the houses were less than 40 years old, there is a good chance these buyers hadn\u0026#8217;t bothered with surveys. How this relates to big product decisions Working in product management, I make many decisions every week. There are countless examples of me getting things wrong because of cognitive bias which have cost my teams time and money. Here are just a few: Taking too long to change the strategy (sunk cost fallacy) Hesitating to take risky decisions due to attaching too much weight to fear of loss (loss aversion) Persevering with a feature despite user research indicating that it is unlikely to have the desired impact (confirmation bias) Overestimating product demand/benefits (optimism bias) Underestimating cost/effort (planning fallacy) Prioritising features because that is what has worked for me before and what others seem to be doing (anchoring bias) Overestimating my own knowledge about an area that I don\u0026#8217;t understand well enough (Dunning-Kruger effect) This is just a very short list of cognitive bias that can get in the way of decisions. For a complete list, check out this awesome cognitive bias codex from Wikimedia. The techniques for dealing with these cognitive fallacies apply to product management, house buying and most other domains where decisions need to be made. Which is good news for geeks like me who like trying to apply product management principles to their lives! Here are some of the techniques that work. Dealing with cognitive bias Mindfulness Paying attention to my thoughts helps me identify when I might be experiencing some sort of cognitive bias. If something doesn\u0026#8217;t feel right, I have the tendency to try to brush over it, ignore it and press on. But feelings of discomfort like this should be a signal that something requires further investigation. Write things down in decision tables I think by writing. I think particularly well by writing things down in decision tables. The types of decision tables I like to use are: Simple pros and cons table Pros on the left. Cons on the right Good for simple decisions or starting out with thinking More complex decision matrixes with multiple criteria. My go to format is: Treat each option as a column Treat each factor as a row Colour-code each cell according to how much it aligns with each option Order rows with the most important factors at the top Good for more complex decisions or where there are more than 2 options Writing and looking at information in this format helps me make better decisions, and provides an objective way for others to understand the factors in a decision and challenge assumptions. Seek information Go forth and gather information, especially from people cleverer than you. Ideally clever people who disagree with you. Definitely from a diverse group. In house buying, this is what I tried to do by speaking to a range of different housing experts. In product management, I do this by discussing with a cross functional team of people who bring different knowledge and perspectives to the table. Time heals On the first day I discovered this issue, I was still set on proceeding as planned. By day two, I was wavering. I woke up one day 3 committed to withdrawing from the purchase unless I could secure a significant discount. After writing things down, I like to sleep on it. I usually wake up with clarity. What a difference a day makes! Those strong emotional reactions that come with cognitive dissonance start disappearing after a day or so. So if I think that might be something I am dealing with, I like to sleep on it if I can. Of course this is not always possible, but I have found that most decisions don\u0026#8217;t need to be snap decisions. Think out loud I like to imagine choosing one of the options. I then try to confidently justify my decision, ideally by chatting it through with a friend or colleague. If I feel crappy about what I am saying or I struggle to answer their questions, that is a good indication that something isn\u0026#8217;t quite right. How will I feel about this in 10 months or 10 years? Thinking long-term can help minimise the short-term and emotional factors in decisions. Losing 6 weeks and £1k of fees on a failed house purchase doesn\u0026#8217;t seem like a big loss on a 10 month or 10 year Horizon. Forcing myself to think longer term can give me perspective. Pre-mortems Pre-mortems encourage us to think creatively about what could go wrong before it happens. This helps expose assumptions that bias might otherwise conceal. I like to do pre-mortems before starting work on new products or features. Setting clear and explicit goals before starting A good habit for product managers to get into is being explicit about the expected impact of a piece of work before you start. This helps mitigate confirmation bias. Forcing you to state upfront what good looks like makes it harder to go off and seek other data to justify decisions after the fact. Setting measurable goals like that can be really hard in practice, and is not a habit I have fully adopted yet for every decision. It is often very hard to quantify the impact of something \u0026#8211; picking the right metrics and the right targets is not easy. That said, it\u0026#8217;s something I am striving to get better at and do more often. Recommended reading Thanks for taking the time to get this far! I hope you found it useful. If you are interested in learning more about how to make better decisions, I recommend Decisive: How to Make Better Choices in Life and Work. ","permalink":"https://alaniswright.com/blog/cognitive-bias-house-buying-and-product-decisions/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  Buying a house is apparently one of the most stressful things you\u0026#8217;ll ever do. You have to make lots of big and expensive decisions. Going through the process for the 3rd time this last few months got me thinking about the cognitive biases involved in the house buying process. Naturally I then started comparing them to the types of decisions I have to make as a product manager (because that\u0026#8217;s the type of guy I am). Which then naturally led to a blog post. Naturally.\n\u003c/p\u003e","title":"Cognitive bias, house buying and product decisions"},{"content":" I have spent most of the past decade developing digital products in domains where truth and accuracy really matter, including government services and public policy. More recently, that has involved a lot of working with AI. This blog post summarises some of the approaches to AI product management that I have seen work well and that have worked well for me in high-stakes domains 1: User value comes first This one comes #1 in the UK Government Design Principles, Google\u0026#8217;s People \u0026 AI Guidebook and pretty much everything Marty Cagan has ever written. In the AI domain, this means only considering AI solutions when they have the potential to help solve problems for users better than non-AI alternatives. It also means thinking very hard about how your AI solution offers value over and above what a user can get on existing general-purpose tools like ChatGPT. AI tools are not cheap to develop, and users need good reasons to continue using a product. For example, decision-makers in the law and policy domain need very accurate data, and they want to be able to verify for themselves where that data has come from. Adding a ChatGPT-powered chatbot on top of a long text document would not have offered users a meaningful improvement over existing AI tools they have access to. Instead, Climate Policy Radar has focussed on building capabilities that address the core needs of decision-makers in the climate domain. These include mapping unstructured data from PDFs into a knowledge graph of structured climate law \u0026 policy data to make it easier to find relevant content. It also means showing the user the exact passages of text from documents that support claims made by AI models to help users verify the claims made by AI. These capabilities help users to discover insights from long climate documents, faster and more reliably. 2: Use cross-functional teams Supervised learning is one of the main techniques used to teach AI models what they know about a topic. This technique relies on labelled data for both training and evaluation. Domain experts are needed to create the labelled data. Data scientists develop the models which consume the labelled data to predict the meaning of the text. Data and application engineers productionise these models. Product and UX experts incorporate these models into user experiences that are usable and valuable and plan how to take them to market. It is accepted wisdom that good teams are diverse teams. This is especially important for teams developing AI products because AI is a fast-moving complex domain where design and technology conventions are only just beginning to emerge. I learned a lot about what good cross-functional teams look like during my time at the UK\u0026#8217;s Government Digital Service. It is good to see the tradition continuing at the Government\u0026#8217;s AI Incubator, and that the list of specialist roles has expanded to include more AI-specific roles. Cross-functional AI team roles being advertised for by the UK Government\n3. Augmentation over automation Automation is when AI completes an action without human intervention. Augmentation is when AI and a human need to work together to complete an action. When people are responsible for something, they want (and sometimes need) to maintain control over it. So AI in domains where the cost of failure is high tends to require a human in the loop. A great example of AI augmentation can be found at Full Fact, a fact-checking organisation based in the UK. They use AI to help their fact checkers work faster \u0026#8211; not by trying to replace them with AI. Similar approaches can be found in the medical domain, with AI helping specialists do MRI scans faster. Automation can go spectacularly wrong in high-stakes domains. Mistakes by automated systems in the US have left people bankrupt, deprived of healthcare services and rejected from jobs. This poor guy went bankrupt because of a mistake by an automated system\n4: Avoid garbage in, garbage out High-quality machine-readable data is critical for AI models. After all, if data can\u0026#8217;t be read by machines then it cannot be used by AI. And if data is read incorrectly by machines, then it is unlikely to generate a useful result. This makes high-quality structured data a top priority for any digital product or service. This was true in digital transformations I have worked on like those at the Land Registry where they are trying to digitise the Land Register, and move from Tetris to LEGO in the process. It is particularly true for AI products. Climate Policy Radar works mainly with Government laws and policies, which are usually long text documents in PDF form. PDFs are notoriously difficult to extract data from. Actively measuring the quality of text extracted from PDFs and improving accuracy improves every area of the product where the machine readability of text from PDFs matters (which is pretty much all of them). ChatGPT won\u0026#8217;t be of much help if it can\u0026#8217;t detect any text in the document you upload to it. Good data quality enables users, search algorithms, transactional services and AI models to generate better insights from data, faster and at lower cost. 5: Move fast and break things AI is a game-changing technology. But since ChatGPT 3 burst onto the scene, it has earned a bit of a reputation for inaccuracies, biases and hallucinations. People in high-stakes decisions have low tolerance for these types of issues. Move fast: yes. Break things: no thanks. Here are some of the things that can go wrong with AI models: Misunderstanding intent. If an AI tool misunderstands a user’s question, it is very unlikely to give a useful response at all. Equity \u0026 inclusion. AI models can amplify biases that affect certain groups. There are some examples going around about AI models being used to screen job applicants, unfairly screening out candidates from underrepresented groups. You can easily imagine the ways in which this could go wrong if used to decide who qualifies for Government support from critical services. False positives occur when results are included when they should be excluded. Minimising false positives is important in domains like fraud detection or spam detection where inaccurate predictions have a high cost. Precision is the name of the metric that measures false positives. False negatives occur when results are excluded when they should be included. For thorough research where it is important that no evidence is missed, minimising false negatives can be more important. Recall is the name of the metric that measures false negatives. It is important to measure and minimise both precision and recall but at a certain point, they start to trade off against each other. Which one to optimise for varies by the type of product being built. Domain switch occurs when a model is used to give results in an area which it was not trained to. This increases the likelihood of inaccurate results. GOV.UK get around these problems by triaging out users who want to ask questions which their experimental chat tool is unlikely to answer effectively. GOV.UK chat is making sure I plan to ask it questions about a domain it has been trained on before allowing me to access their experimental AI tool\n6: Measure performance Measuring performance is one of the key tenets of a good and responsible AI strategy. Expert human labellers create evaluation datasets to measure model performance. This allows the accuracy of AI classification models to be measured. Climate Policy Radar\u0026#8217;s Queried prototype is experimenting with ways to surface these scores to users to help them understand the accuracy of AI responses. Climate Policy Radar’s Queried prototype automatically checks AI answers for quality and accuracy\nEquity and bias can be understood by ensuring that a good amount of evaluation data comes from underrepresented groups. In the domain of written content on the internet, that means things like ensuring there is a good amount of data from underserved regions of the world or content that is not written in English. Measuring data quality and experimenting with ways to improve it is also important, as none of the above works without good data. For text data, this includes making sure text is extracted from documents and that the text extracted retains its original meaning and structure. Metrics like these help teams to understand where they are doing well, and where they can do better. As a product manager, this helps me decide where to prioritise future improvement efforts. 7: Make things open This is another one I have shamelessly borrowed from the UK Government Design Principles. Being open means several things here. Making code and data more open accelerates impact, enabling others to learn from, reuse and build on top of good work. Being open isn\u0026#8217;t just about doing good in the World. With a section heading \u0026#8220;Move fast and break things\u0026#8221; I poked a bit of fun at Meta. But Mark Zuckerberg\u0026#8217;s focus on open-source AI makes commercial sense. Being open means that data and models are open to others to improve and scrutinize, which helps make them better. (In Meta\u0026#8217;s case, it also helps them undercut competitors.) Being able to verify information in order to understand how much it can be trusted is a core need of users working in high-stakes domains. Features that really excite me in this space include: A. Highlighting relevant text. Displaying citations for all claims made by AI models and enabling users to find the exact passages of text in documents that match their query helps users quickly judge the accuracy of AI responses. NotebookLM identifies the passages of text in a document that support claims made in their AI response\nB. Transparency. Being transparent with information used to construct a response helps users figure out how accurate an AI response is The Consensus Meter (by Consensus) helps users understand how much agreement there is in the answer to scientific questions\n8: Continuous feedback Last but not least, it is important to build in ways to gather continuous feedback from users. This makes it easier to identify improvements and can provide useful training data to help fine-tune models. Thumbs-up/thumbs-down features on key page elements help gather structured feedback. A user labelling search results, metadata or answers as good or bad could be used to help improve the underlying algorithms. Gemini make it easy for users to feed feedback on results via thumbs up or down, and then prompts users to give extra feedback\nQualitative data is also critical in fast-moving domains like AI. User behaviours are evolving fast and this is a great way to understand why users are behaving the way they are. I like to sprinkle lots of micro surveys throughout the products I am responsible for to get a sense of what matters to users. This also helps me get lots of conversations started with users. I liberally share a Calendly link for users to sign up for a feedback conversation everywhere I can. Overall None of the 7 points in this post are unique to AI products. But the power, complexity, novelty and data-driven nature of this new technology make them especially important. Especially so in domains like government, news and policy where there is a premium based on accuracy and truth. Not for the first time, I also want to give a shout-out to Henry Franks, Kalyan Dutia, Harrison Pim, Matyas Juhasz and Michal Nachmany from whom I have learnt so much about AI over these past few years. Other AI blog posts written by me Google AI Pro: Image Editing, Deep Research and Fantasy Premier League AI prompt engineering as a product manager 6 ways I like to use ChatGPT 8 ways I am using AI to help me be a better product manager (and 4 ways I am not) ","permalink":"https://alaniswright.com/blog/ai-product-management-in-high-stakes-domains/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  I have spent most of the past decade developing digital products in domains where truth and accuracy really matter, including government services and public policy. More recently, that has involved a lot of working with AI. This blog post summarises some of the approaches to AI product management that I have seen work well and that have worked well for me in high-stakes domains\n\u003c/p\u003e\u003cfigure class=\"wp-block-image size-large\"\u003e\n\u003cp\u003e\u003ca href=\"https://alaniswright.com/wp-content/uploads/2024/12/image.png\"\u003e\u003cimg loading=\"lazy\" decoding=\"async\" width=\"1030\" height=\"716\" src=\"https://alaniswright.com/wp-content/uploads/2024/12/image-1030x716.png\" alt=\"\" class=\"wp-image-964\" srcset=\"https://alaniswright.com/wp-content/uploads/2024/12/image-1030x716.png 1030w, https://alaniswright.com/wp-content/uploads/2024/12/image-300x208.png 300w, https://alaniswright.com/wp-content/uploads/2024/12/image-768x534.png 768w, https://alaniswright.com/wp-content/uploads/2024/12/image-705x490.png 705w, https://alaniswright.com/wp-content/uploads/2024/12/image-450x313.png 450w, https://alaniswright.com/wp-content/uploads/2024/12/image.png 1072w\" sizes=\"auto, (max-width: 1030px) 100vw, 1030px\" /\u003e\u003c/a\u003e\u003c/figure\u003e\u003c/p\u003e","title":"AI product management in high stakes domains"},{"content":" As a product manager and all-around data nerd, analysing product and user data is something that brings me joy. This is convenient, as understanding users and analysing data are two of the biggest parts of my job. In this post, I share some of the tools and data sources I like best. Due to copywrite restrictions, ChatGPT could not create a collage of the logos of all the tools mentioned in this post. But it did create me an image that features visual elements inspired by these tools\nProduct analytics Useful for: quantitative data on user acquisition, engagement and retention Product analytics tools give me access to quantitative data about where users are coming from, how they are accessing my tools, how they are using the product and how often they return. This enables me to answer questions like: how are users finding the product? how did that marketing campaign perform? are we increasing the percentage of new users who we convert into active users? at which stage in the process are most users dropping out? how do different segments of users behave on the site? how do users behave over time? Google Analytics is the market leader in web analytics, and every digital product I have ever been involved in uses it. So long as it is free, I will continue to use it because it is the tool most people are most familiar with, and more people on the team having the ability to access analytics can only be a good thing. More recently, I have primarily been using PostHog as my product analytics tool of choice. I like that it gives fine-grained control over event tracking, the ability to run SQL queries from within the product and powerful capabilities to build up my own analytics dashboards from the ground up. Cookie-less product analytics Useful for: understanding the total number of user sessions The limitation with tools like Google Analytics is that they only work if users accept cookies. The percentage of users who click the accept button varies widely between websites, but it is fair to say that most people do not. This means that a large percentage of users are ignored by cookie-based analytics. This can be problematic if relying on these metrics to give an accurate view of total user numbers, or if users who accept cookies behave differently from those who reject. To get around this, I like to supplement cookie-based tracking with a more limited set of analytics which works regardless of whether users accept cookies. The big limitation of cookie-less tracking is it does not allow you to identify user activity across multiple sessions. For each new session, you have no idea whether it is from a new or returning user. What you do know is the total number of sessions, and what the user is clicking on in each session. Combining cookie-based and cookie-less tracking gives a more complete view of user activity. PostHog has support for cookie-less analytics tracking. I have heard that server-side tracking tools can also be useful here, but that is not something I have tried. Session recording Useful for: seeing how users are actually behaving on the product Session recordings show anonymised recordings of how real users are using my products. They allow me to see where users type, click, scroll and move the mouse as they navigate. Session recording software is often complemented with heatmaps which show which parts of the page are getting looked at more and less. Session recordings are most useful when a trend has already been identified by quantitative analytics, and I want to understand why something is happening. It can help me answer questions like: why aren\u0026#8217;t many users getting to that stage in my funnel? do users understand how to use my new feature? are there parts of my product that are causing frustration? why is my product performing worse on certain devices? There is no substitute for user interviews where you can watch how real users are using the application and ask them questions as they go. However, session recordings are a good compliment. In an hour, I can watch as many as 20 session recordings, so it is a great way of generating insights quickly. I can also easily share recordings in Slack channels or presentations to get the data in front of the team. I like to use HotJar for session recording. It integrates well with Google Analytics and seems to be the market leader in this field. PostHog also have session recording functionality which I have heard good things about but I have not tried it yet. A/B testing Useful for: understanding with high confidence which features or functionality work better for users A/B testing involves showing two or more versions of a product to different groups of users, and seeing which version performs best according to a set of pre-defined metrics. It enables objective, evidence-based and data-driven product decisions, and can reduce the risk of change by testing early with a smaller subset of users. A/B testing helps product managers answer questions like: which button colour increases the likelihood the button is clicked? which marketing message do users respond to best? which content recommendation algorithm is most likely to get more users clicking on related content? does this new feature increase the time a user spends on our site? are there any unexpected negative impacts caused by this new feature? There are limitations to A/B tests. For example, short-term metrics may not align well with long-term user goals. It can take time to build up to statistical significance. Tests can interfere with each other. There is also an administrative overhead involved in running and evaluating tests. One substitute for A/B testing is to keep track of when product changes happen and monitor how different cohorts of users behave. For example, if we monitor key acquisition and engagement metrics for users who use the site in a given week and we see a sudden change, that might indicate that something we have done has had an impact. It might not be caused by anything we have done or might not be statistically insignificant, but it is still a signal that is worth digging into a little further. SEO Useful for: understanding which search terms users enter to find the site and which pages they land on the most SEO (short for search engine optimisation) is the practice of optimising content so that more users can find it via search engines. Although many predict AI tools will imminently replace search engines, tools like ChatGPT search and Perplexity indicate that even if Q\u0026A with an AI do replace traditional search engines, there will still be a place for surfacing the content that these AI tools cite in their responses. Google dominates the market for search engines with more than 90% market share, so is by far the most important one to track. There are two tools I like to use for this. Google Search Console is a free tool that helps people understand how their site is performing in Google Search. It helps me answer questions like: how have click-through rates, impressions, and average position in search results varied by page over time? which pages and keywords are attracting the most traffic to my site? which sites are linking to mine SEMRush is a more general-purpose tool for online marketing tracking. I like to use the free version to help me answer questions like: which keywords are users using the most (in general, not just on my site). This helps me understand what terms I might want to target how are my rankings for different search terms changing over time? what technical and content changes can I make to improve my performance in search engines? Surveys Useful for: gathering feedback from users Surveys are a great way to gather direct insights from users. Unlike all other tools in this post so far, they focus on what users say rather than what users do. They also offer a way to get the conversation started, and are a great source of user research participants. Examples of surveys I like to run include: \u0026#8220;Did you find what you were looking for\u0026#8221; micro-surveys. These are one-question surveys which ask a user a single-choice question, followed up with an optional comment field for those who want to share more. Great for quickly getting a sense of user satisfaction or thoughts on a topic. Micro-surveys to request or feedback on a specific feature. These can be useful to help decide how users want you to extend a feature, or whether they want you to build a feature at all. Low user engagement with this type of survey can be an indication in itself that the feature is not wanted. Survey to access a feature. Features such as data downloads often require users to fill in a survey first. Willingness to fill in such a survey and the data provided when they do can help product managers understand what problem users are trying to solve with the feature. Jobs-to-be-done surveys. A JTBD (Jobs to be Done) survey helps organisations understand the types of tasks that people are doing and how difficult they find them. This helps product managers to decide which problems to focus on solving for users. These surveys are quite long-form surveys and usually take a few minutes to fill in. My favourite survey tool is JotForm. It enables all of the survey types listed above, as well as bespoke emails/confirmation pages depending on how questions are answered. I have heard good things about SurveyMonkey and TypeForm too. Google Forms is also a good choice for simple surveys. User conversations Useful for: building a rich understanding of users \u0026#8211; their goals, problems to solve, and how they are solving those problems today Last but most definitely not least: I have conversations with people who actually use my products. There is no substitute for conversations with real-life users, and if I had to pick one thing from this list it would be this. I have blogged before on the importance of user research and how I am doing user research at a start-up, so I will keep this last one brief. Calendly is my tool of choice for scheduling user feedback conversations. It allows users to schedule time with me and automates the collection of all the relevant consents. I liberally share this link to my calendar at every opportunity. Dovetail is a tool I only started using two weeks ago but I am already loving it! It makes it easy for me to analyse recordings of user research sessions, extract insights and make those accessible to my team. ","permalink":"https://alaniswright.com/blog/my-favourite-tools-for-analysing-user-and-product-data/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  As a product manager and all-around data nerd, analysing product and user data is something that brings me joy. This is convenient, as understanding users and analysing data are two of the biggest parts of my job. In this post, I share some of the tools and data sources I like best.\n\u003c/p\u003e\u003cfigure class=\"wp-block-image size-full\"\u003e\n\u003cp\u003e\u003ca href=\"https://alaniswright.com/wp-content/uploads/2024/11/image-6.png\"\u003e\u003cimg loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"1024\" src=\"https://alaniswright.com/wp-content/uploads/2024/11/image-6.png\" alt=\"\" class=\"wp-image-938\" srcset=\"https://alaniswright.com/wp-content/uploads/2024/11/image-6.png 1024w, https://alaniswright.com/wp-content/uploads/2024/11/image-6-300x300.png 300w, https://alaniswright.com/wp-content/uploads/2024/11/image-6-80x80.png 80w, https://alaniswright.com/wp-content/uploads/2024/11/image-6-768x768.png 768w, https://alaniswright.com/wp-content/uploads/2024/11/image-6-36x36.png 36w, https://alaniswright.com/wp-content/uploads/2024/11/image-6-180x180.png 180w, https://alaniswright.com/wp-content/uploads/2024/11/image-6-705x705.png 705w, https://alaniswright.com/wp-content/uploads/2024/11/image-6-120x120.png 120w, https://alaniswright.com/wp-content/uploads/2024/11/image-6-450x450.png 450w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" /\u003e\u003c/a\u003e\u003cfigcaption class=\"wp-element-caption\"\u003e\u003cem\u003eDue to copywrite restrictions, ChatGPT could not create a collage of the logos of all the tools mentioned in this post. But it did create me an image that features visual elements inspired by these tools\u003c/em\u003e\u003c/figcaption\u003e\u003c/figure\u003e\u003c/p\u003e","title":"Tools for analysing user and product data"},{"content":" The past few months have been busy for me! I have been trying to sell my house and find somewhere new to live. In September, I had an offer accepted on an awesome place (woop woop!). Assuming the sale doesn\u0026#8217;t fall through (a big assumption in England), and assuming this is actually my forever home (also a big assumption), I will not be looking at Zoopla or Rightmove again for quite a while. This feels like a shame, as in recent years figuring out places where I might want to live has become a favourite hobby of mine. I have an app called Freedom on all my devices that keeps me off news and social media. But I didn\u0026#8217;t set it up to block property websites, so that is where I have tended to go when I enter the dark playground of infinite scroll and procrastination. Over the years, I have also found a fair number of other digital tools that have helped me decide which part of England to live in, and which properties are most suited to me. This post summarises the ones that I have found to be most useful. If you think of any good ones that I have missed, get in touch and I will add them to the list. An AI’s answer to the question “generate an image to illustrate digital tools to help people find the right house”\nDigital tools I like to use Travel Time is a great app that allows you to see at a glance which places are within a reasonable distance of London stations. My aim was to get further out of London and nearer to the South West of England (my parents live in Dorset and there are excellent beaches down there)! I also needed to be within easy commuting distance of London for work. Finding somewhere to live a decent commute from Climate Policy Radar‘s Waterloo office\nTraffic noise is something I can\u0026#8217;t stand. Extrium shows noise from cars and trains on a map. Fast cars are the worst in my opinion, so this map of speed limits comes in handy too. Finsbury Park: lovely park. Shame about the traffic noise\nAeroplane noise isn\u0026#8217;t as bad as cars, but I did not want to live under a flight path. Flight Radar is a good app to check out if this matters to you. This made me feel better about not being able to afford to live in Richmond!\nFlood risk is sadly likely to become more of a thing in my lifetime. This urban water map is useful for checking out London properties. I was not able to find a UK-wide map of flood risk, so I tended to use this height above sea level map as a substitute. GOV.UKs check the long term flood risk for an area in England is the place I go for a more detailed look once I have a specific property in mind, as it only works with specific postcodes. Maps like this have put me off more than a few good looking properties\nAir pollution is a thing if you are living in London. London Air\u0026#8216;s annual pollution maps give a good sense of which places to avoid. TLDR: avoid busy roads! TLDR: the air is a lot nicer further out of London\nOne of the questions I usually ask when looking for a house is what the opportunities for future expansion are. Google Earth is a great tool for quickly checking whether neighbours have done loft or rear extensions. Local council planning websites are useful for a more detailed look. You can read planning documents from the applications of previous owners or neighbours. As I approached my forties, gardening became a favourite hobby of mine. Good plants don\u0026#8217;t like lots of shade. ShadeMap gives you an idea of how much light a garden will get at different times of day/year. Zoopla and Rightmove often advertise houses without the address. This is annoying as most of my questions above can be answered quickly by knowing the exact location of the property. If I can\u0026#8217;t make out the house number from the photo, I use Google Streetview to figure out the address from what the front of the house looks like. Pro-tip for Zoopla and Rightmove: occasionally scan through saved searches for places that have quietly become available again. If a house goes off the market and then comes on again soon after/without a big price change (eg. because a sale collapsed), users will not get automatically notified. There will be less competition for properties like this unless the agent is particularly well-connected with potential buyers in the area via other listings. When deciding what offer to make, Zoopla\u0026#8217;s sold house price predictions give a useful idea of how much the property might be worth. Rightmove just shows the historical sale price, but Zoopla shows the sale price plus their estimate of how much it\u0026#8217;s worth now. The feature has been nerfed recently, and now you have to click a lot before you can find the Zoopla estimate of a property, but it is still better than nothing. Click ‘See what it’s worth today’ and then press a few buttons to get an estimate of the current property value on Zoopla\nDo yourself a favour and get a decent conveyancer Once your offer is accepted, finding a good conveyancer is critical. Buying a house is one of the most stressful things you will ever do, and it is one of those times when it really is worth paying a little bit more for a pro to get it done for you. I highly recommend Juno to anyone who will listen. The first time I bought a property I went for someone cheap. The whole process took months longer than it needed to, and I drowned in legal terminology and printed bits of paper. Juno was recommended to me by ex-colleagues on GOV.UK. Like GOV.UK, they have gone to a real effort to explain complex services in a simple way, More recently, they have built an easy-to-use portal which looks a bit like a blue version of a GOV.UK service. I am hoping we can both make £75 from Juno\u0026#8217;s referral scheme now! ","permalink":"https://alaniswright.com/blog/my-favourite-digital-tools-for-house-hunting-around-england-and-london/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  The past few months have been busy for me! I have been trying to sell my house and find somewhere new to live. In September, I had an offer accepted on an awesome place (woop woop!). Assuming the sale doesn\u0026#8217;t fall through (a big assumption in England), and assuming this is actually my forever home (also a big assumption), I will not be looking at Zoopla or Rightmove again for quite a while.\n\u003c/p\u003e","title":"Digital tools for house hunting around England and London"},{"content":" Product discovery is all about uncovering user problems and validating solutions to those problems quickly. When teams start discovery without preparation this can lead to wasted time, wasted effort and bad solutions. This post explores my thoughts on how best to help teams prepare for product discovery (aka pre-discovery). 1. Explain the big picture Want to minimise the risk that the discovery team sets off in the right direction? Here are a few questions to consider before the team gets started: Why has this discovery been prioritised? Why now? What problems need to be solved? What business objectives or results are the team expected to achieve? Are there any constraints, risks or deadlines the team need to be mindful of? And most controversially, what solutions do senior leaders already have in mind (if any) and why? Discovery teams rarely like to be told what solution to build (for good reason). However, if senior leaders do have expectations, it is good to at least understand what they are and why they exist, and it is better to know sooner rather than later. Teams should have the licence to challenge these assumptions and come up with alternative ideas. Kuba Bartwicki\u0026#8217;s post In defence of sometimes starting with solutions is well worth a read on this topic. 2. Prepare a cross-functional team Cross-functional teams bring diverse perspectives and expertise to the product discovery process. Doing discovery together leads to better solutions, faster decisions and a more aligned team. Discovery is about reducing risk. Cross-functional teams identify risks earlier and identify better solutions to those risks faster. Which roles need to be in the cross-functional team? It depends on the problem and context. Some of the discovery teams I have worked on in Government have included product management, delivery management, user research, content design, service design, analysts, data scientists, engineers, operations, procurement, legal, marketing, sales and SMEs. I have also seen discovery teams of two very T-shaped individuals who wear many of these hats at once. My personal preference is usually for smaller teams as they can move faster and have lower costs. The key thing is that there are people on the team who can understand and mitigate the four key product risk areas: business value, user value, usability and technical feasibility. It isn\u0026#8217;t necessary (and it usually isn\u0026#8217;t practical) for all team members to be full-time on the discovery. That said, small teams of people who focus on one problem at a time can usually deliver results better and faster. If working with part-time team members on a discovery, starting and finishing discovery are the two most important activities for the team to do together. 3. Start together It can be tempting for individuals to get started with discovery before the wider team is ready. This can be problematic for multiple reasons: Loss of tacit knowledge. When small teams go through the discovery process together, they gain knowledge from synchronous collaborative interactions that is difficult to replicate in documentation. When teams miss out on this, they risk missing out on the nuanced understanding and context that comes from collaborative discovery. Inefficient use of time. Work done alone is at higher risk of needing to be repeated or significantly revised Lack of buy-in from team members. Team members often feel less invested if they are not involved from the beginning, leading to an increased risk of disengagement Premature solutionisation. Individuals getting started ahead of others can lead to confirmation bias and narrow thinking, leading to substandard solutions. If some team members are available to start ahead of others, they should limit their discovery work to conducting secondary research to gather pre-existing information. Or removing potential blockers like the ones listed in the section below. Primary research should generally wait until the discovery team is ready to start together. 4. Remove potential blockers Slow discoveries are expensive. Here is a short list of things that often slow down discoveries, along with some tips for how you can reduce the risk of them slowing you down. Stakeholder buy-in or availability. Internal stakeholders include roles like legal, sales \u0026 operations. External stakeholders include partner organisations who you are developing the product with. Discovery usually can\u0026#8217;t get very far without all the right people available, so getting their buy-in and getting conversations scheduled with busy stakeholders in advance can reduce the risk that this blocks the team. Access to users. There is always a lag between identifying users and being able to speak to them. Line up relevant users to speak to in advance so that round 1 of user research can start in week 1 of discovery. Access to data. This includes performance analytics for existing solutions, customer support data, existing insights about user needs/problems and results of any previous discovery work done in the space. Ask on your company\u0026#8217;s equivalent of Slack to see if anyone else at the company has worked on similar problems before and ask them to point you towards the documentation Tools and facilities. Make sure everyone has access to the tools the team need to use in the discovery. Tools for note-taking, action tracking, video conferencing, instant messaging and virtual whiteboarding will all be essential from day one. 5. Plan ahead for delivery The goal should be to move swiftly into delivery once discovery is complete (or complete enough for the team to have enough confidence that they are not about to start building the wrong thing). Why does leaving gaps between stages lead to waste? Loss of momentum \u0026 context. Insights generated during discovery fade with time, especially tacit knowledge which is difficult to write down. The longer the gap, the higher the cost of delivery, and the higher the risk of a lower-quality solution. Outdated knowledge leads to wasted effort. We work in a fast-moving industry working with fast-moving technologies. Gaps between stages increase the risk that insights are outdated by the time work begins and then need to be re-done Disconnect between discovery and delivery. Long gaps increase the risk of having to change team members between discovery and delivery. These handoffs between knowledge workers come at a cost When preparing a team for discovery, leadership should try to make some educated guesses about how long the discovery will last, and what shape of team will be needed to deliver on the discovery findings. They won\u0026#8217;t always get it right. But it is easier to find valuable work for an engineering team at short notice than it is to find an engineering team at short notice to do valuable work. This can get very difficult when suppliers or partners are involved, but it is not impossible. If contracting with a supplier or partner for a discovery, think in advance about how you might move fast into delivery once the discovery is complete, and provision for this from the beginning. Winning new business – an important exception In the real world, design work or prototypes are often needed to win new business, develop a partnership or secure funding. I am not suggesting that we need to put in place a discovery team to do these types of pre-sales activities. Instead, a small team should put together some high-level concepts which show the type of solution that will be possible. The goal should be to persuade the client/partner/executives that the work is worth committing to. More often than not I have seen discoveries come up with different and better solutions than what was initially assumed, so it is important to educate all involved that some discovery work will need to take place before delivery starts. Thanks for reading The phrase \u0026#8220;strong opinions loosely held\u0026#8221; is especially true for this post! Please do get in touch if you have any feedback. ","permalink":"https://alaniswright.com/blog/pre-discovery-how-to-prepare-for-product-discovery/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  Product discovery is all about uncovering user problems and validating solutions to those problems quickly. When teams start discovery without preparation this can lead to wasted time, wasted effort and bad solutions. This post explores my thoughts on how best to help teams prepare for product discovery (aka pre-discovery).\n\u003c/p\u003e\u003cfigure class=\"wp-block-image size-large\"\u003e\n\u003cp\u003e\u003ca href=\"https://alaniswright.com/wp-content/uploads/2024/08/image-7.png\"\u003e\u003cimg loading=\"lazy\" decoding=\"async\" width=\"1030\" height=\"492\" src=\"https://alaniswright.com/wp-content/uploads/2024/08/image-7-1030x492.png\" alt=\"\" class=\"wp-image-887\" srcset=\"https://alaniswright.com/wp-content/uploads/2024/08/image-7-1030x492.png 1030w, https://alaniswright.com/wp-content/uploads/2024/08/image-7-300x143.png 300w, https://alaniswright.com/wp-content/uploads/2024/08/image-7-768x367.png 768w, https://alaniswright.com/wp-content/uploads/2024/08/image-7-1536x733.png 1536w, https://alaniswright.com/wp-content/uploads/2024/08/image-7-1500x716.png 1500w, https://alaniswright.com/wp-content/uploads/2024/08/image-7-705x337.png 705w, https://alaniswright.com/wp-content/uploads/2024/08/image-7-450x215.png 450w, https://alaniswright.com/wp-content/uploads/2024/08/image-7.png 1598w\" sizes=\"auto, (max-width: 1030px) 100vw, 1030px\" /\u003e\u003c/a\u003e\u003c/figure\u003e\u003c/p\u003e","title":"Pre-discovery. How to prepare for product discovery"},{"content":" For years I used Evernote to store my notes and Trello to track my actions. For the past 2 years, I have been using Obsidian for both. This post summarises how and why I am using Obsidian. Credits again go to Henry Franks for putting me on to this! Why I like Obsidian Obsidian is a note-taking tool based on Markdown, an open document format that creates formatted text. It has a huge community who have built a wide range of awesome open-source plugins and themes. After the pain I went through migrating away from proprietary tools like Trello and Evernote a few years ago, I like that Obsidian is based on an open format. It makes it easy to migrate all my content to a similar tool if I so wish, which should keep them competitive. I also like that I can have all my actions and notes in one place. This minimises the need to duplicate information in different places. My Obsidian process Warning to any Obsidian power users reading this: I have opted for a much simpler Obsidian process than most of the ones I have read about online! Inbox Every time I think of something new (idea, reflection, action, etc) I usually add it to my Inbox note. This is easily accessible from my mobile phone\u0026#8217;s home screen with just one tap. I do my reviews every week, so my inbox gets processed at least that often. My weekly note is where I keep track of notes, lessones learned, habits, and actions. I also store my quarterly review notes in Obsidian. Read more about my process for weekly and quarterly reviews. My Obsidian vault is of course called ObsidiAlan. Here is my folder structure and the top half of my weekly note template\nBrain For longer-form writing or notes about specific topics, I add a new note directly to my Obsidian \u0026#8220;Brain\u0026#8221; folder. All new notes go here by default unless I manually move them elsewhere. Each note can be given tags and linked with other notes to form a visual graph of notes. I haven\u0026#8217;t made use of either of these features enough to see real value from them so far, but I link to all the main notes I\u0026#8217;ve used in each weekly note so that I can avoid making the note itself too detailed. Actions Typing \u0026#8220;- [ ]\u0026#8221; before a line of text creates a checkbox item. A checkbox item is an action, and it can be added to any note. Actions can be assigned tags and due dates, which make them easy to track. They can also be viewed in different places, which reduces the need for duplication. I have a view of all of my outstanding actions at the bottom of my weekly note template. All the actions appear in the bottom half of my weekly note template. Need to water those plants!\nMultiple tabs Obsidian allows you to open an unlimited number of tabs, and to arrange them into custom layouts. I usually have at least two tabs open at a time \u0026#8211; one for reading and one for writing. Within Obsidian, I can view different combinations of notes and drawings at one time. Neat!\nMy favourite extensions Obsidian sync Obsidian is free to use and open source, but Obsidian Sync is available for about £80 per year. It keeps Obsidian in sync across all my devices. I initially tried to be cheap and avoid paying this, instead relying on Google Drive to sync my Obsidian vault. But after losing 8 hours worth of notes from a long plane journey, I decided to cough up the money and haven\u0026#8217;t looked back since. Omnisearch Omnisearch is more powerful and easier to use than the default Obsidian search. Omnisearch\u0026#8217;s algorithm gives increased weight on the words in your search phrase appearing together and/or in the title, which leads to more relevant results. The screenshots below illustrate the difference. The only time I use the default Obsidian search is when I know roughly when a note was written or edited. In those cases I used the default search with files ordered by date modified. Omnisearch (on the right) gives more relevant search results than the default Obsidian search Periodic notes I use the periodic notes plugin to generate my weekly notes (though it can also be used to generate daily, monthly or quarterly notes). All of these regular notes belong in a specific \u0026#8220;weekly notes\u0026#8221; folder and use a consistent template/naming convention. Clicking the \u0026#8220;Open this week\u0026#8221; button in my sidebar allows me to quickly access this week\u0026#8217;s note, or create this week\u0026#8217;s note if it doesn\u0026#8217;t already exist. Excalidraw Sometimes I need to draw diagrams or sketch out ideas. If at work I might use Miro or Whimsical to do this, but I don\u0026#8217;t have a personal license for those tools. So I tend to fall back on tools like Paint or PowerPoint. Excalidraw is a drawing app built into Obsidian that is basic but impressive. I like that it has a sketch mode which makes all the drawings look slightly lower fidelity. There are also lots of freely available extensions to make Excalidraw more powerful Minimal theme Technically not an extension, but Minimal is my favorite Obsidian theme. As one of the most downloaded themes, it loads fast and strips out a lot of the noise that exists in some of the alternatives. Mobile app – room for improvement Obsidian only recently launched a mobile app. It is a bit frustrating as it doesn\u0026#8217;t include any widgets and it takes a few seconds to load each time I try to open up a note. I have got around these slow loading times by using a third-party app called Markor to add content to my inbox and create Markdown files in my Obsidian vault. Leaving the Obsidian app always open helps too! It would be great to see the Obsidian app developed to load faster and be able to do some of these things natively. I wish Obsidian opened as fast as Markor…\n","permalink":"https://alaniswright.com/blog/how-i-use-obsidian-to-keep-track-of-personal-notes-and-actions/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  For years I used Evernote to store my notes and Trello to track my actions. For the past 2 years, I have been using Obsidian for both. This post summarises how and why I am using \u003ca href=\"https://obsidian.md/\"\u003eObsidian\u003c/a\u003e. Credits again go to \u003ca href=\"https://uk.linkedin.com/in/henryfranks\"\u003eHenry Franks\u003c/a\u003e for putting me on to this!\n\u003c/p\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"why-i-like-obsidian\"\u003eWhy I like Obsidian\u003c/h2\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  Obsidian is a note-taking tool based on Markdown, an open document format that creates formatted text. It has a huge community who have built a wide range of awesome open-source plugins and themes. After the pain I went through migrating away from proprietary tools like Trello and Evernote a few years ago, I like that Obsidian is based on an open format. It makes it easy to migrate all my content to a similar tool if I so wish, which should keep them competitive. I also like that I can have all my actions and notes in one place. This minimises the need to duplicate information in different places.\n\u003c/p\u003e","title":"How I use Obsidian to keep track of personal notes and actions"},{"content":" In this post, I use my experience of playing Settlers of Catan online during lockdown and onboarding to Arc Browser to illustrate why solving problems for a user is critical if you want them to switch to using your product, and why user value often comes before usability. Product #1: Settlers of Catan (online version) Settlers of Catan is the greatest board game of all time. I love how easy it is for people to gang up on someone who is getting too big for their boots, and that, right up until the end, it\u0026#8217;s so hard to predict who is going to win. I have more than one friendship group where regular games of Catan are one of our main ways of keeping in contact. With the pandemic hitting in 2020 and ever more of my friends living further away, we took to playing Catan online. However, the Settlers of Catan app was rough around the edges to say the least. One amusing example: to start the game you had to click a button that says \u0026#8220;I am not ready\u0026#8221;. When you click it, the button text changes to \u0026#8220;I am ready\u0026#8221;. This confused all of us at first, but has since turned into a bit of a running joke. We now begin games by announcing \u0026#8220;I am not ready\u0026#8221;. Trade was also a constant source of confusion. It was hard to see from the user interface which way round trades were meant to work. Less funny was the constant server instability, or the inability to undo accidental clicks (I once accidentally threw a game by clicking the road button instead of the ship button). Despite all of these issues, we kept on playing the game. Getting ready for Friday night with the lads!\nProduct #2: Arc Browser For Mac users, Arc Browser has become an increasingly popular alternative to Chrome and Safari. Arc are building the \u0026#8220;browser of the future\u0026#8221;. I had heard great things about it from Lenny\u0026#8217;s Podcast and from some of the data scientists at work. For quite some time I had been looking forward to their Windows launch. As a product manager by trade, I was keen to try out this product that had got such rave reviews. However, when the day finally arrived, I felt pretty underwhelmed. I realised that switching from Chrome to Arc Browser was going to take many hours of effort, and I was not sure it was worth it. I have been using Chrome for years, and I have a good system set up making use of work and personal profiles, extensions, keyboard shortcuts and bookmarks. I also like how it is synchronised across all of my desktop and mobile devices. Chrome was not a product I actually had a problem with. And I might be wrong, but from what I saw from that first hour or two, Arc Browser was not sufficiently better than Chrome to make this switch worth the effort. Good things come to those who wait! Three lessons from these examples 1. User value usually trumps usability Two of the most important risks product teams need to overcome in product development are user value and usability. User value is the risk that users won\u0026#8217;t get any value from the solution. Usability is the risk that they will not be able to use the solution to achieve their goal. Arc Browser has excellent usability and onboarding, and some of my colleagues are big fans. But whilst everyone appreciates a good UX, it just was not valuable enough for me to make the switch. Settlers of Catan on the other hand was difficult to use. But we all wanted to play the game so much that we all pushed through the usability and technical issues and played in any case. A lot of users will put up with a crap user interface if the product is valuable enough to them, but few will use a beautiful product that does not help them solve a problem. Check out Marty Cagan\u0026#8217;s Focus on Value post for more on this. 2. Solve a problem for the target user In Lenny\u0026#8217;s Podcast with Bob Moesta \u0026#8211; the co-creator of the Jobs to be Done framework, Bob articulates the four forces that influence whether users switch products or not. Image sourced from Bob’s article on this topic\nHere’s what the math looks like: F1. Push of the situation. Problem with the current solution F2. Pull of the new idea. Benefits of a new solution F3. Anxiety of new solution. Worries about switching F4. Allegiance to current behaviour. Inertia. Existing habits and switching costs (F1 + F2) \u003c (F3 + F4) = No switch. What I’m currently doing works well enough. My cash is staying mine. (F1 + F2) \u003e (F3 + F4)\u0026nbsp;= Switch! I’m onto something new. Please take my money! In my Arc Browser example, I had no problem with my current solution. So there was very little pushing me to switch. I also had a long history of using Chrome and was happy with my setup. In my Catan example, Lockdown was a pretty huge obstacle that prevented us from playing Settlers of Catan in person, so there was no current solution to compete with. The push of lockdown left us with little choice but to try the online game. Solving problems for a user is important, as many users will not even contemplate trying a new product unless they experience real pain with the status quo. 3. People don’t like change There is no shortage of multiplayer video games online. So in the Settlers of Catan example, why did we continue playing an unreliable buggy game for years rather than just play a different game? In Hitchhikers Guide to the Galaxy, Douglas Adams wrote about how people start hating change once they hit the age of 35. As a group of time-poor 35 year-olds, the idea of change was so repulsive to us that we carried on playing a game that didn\u0026#8217;t work properly. Jokes aside, this point is represented by F3 and F4 above. Many users feel anxious about the unknown. Better the devil you know, right? Existing habits are hard to break. That\u0026#8217;s why marketers like to target us at times of great change in our lives such as moving house and going to university, as these are points in time when our habits are changing in any case. It is a window of opportunity where we are more willing than usual to try new things. Switching costs are also particularly high for groups where there is a collective action problem. It is one thing to switch browsers when that is a decision which only affects you. The switching costs for coordinating 6 friends to all switch to a new game are much higher. ","permalink":"https://alaniswright.com/blog/lessons-about-user-value-and-usability-from-settlers-of-catan-and-arc-browser/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  In this post, I use my experience of playing Settlers of Catan online during lockdown and onboarding to Arc Browser to illustrate why solving problems for a user is critical if you want them to switch to using your product, and why user value often comes before usability.\n\u003c/p\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"product-1-settlers-of-catan-online-version\"\u003eProduct #1: Settlers of Catan (online version)\u003c/h2\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  Settlers of Catan is the greatest board game of all time. I love how easy it is for people to gang up on someone who is getting too big for their boots, and that, right up until the end, it\u0026#8217;s so hard to predict who is going to win. I have more than one friendship group where regular games of Catan are one of our main ways of keeping in contact.\n\u003c/p\u003e","title":"Lessons about user value and usability from Settlers of Catan and Arc Browser"},{"content":" In 2018, I wrote a blog post which turned out to be one of my most popular: How I stay organised using Trello, Kanban, GTD and Inbox Zero. A lot has changed in the past 6 years! Wunderlist is no more. Trello has been acquired by Atlassian. I am no longer using personal Kanban. And there\u0026#8217;s a lot that hasn\u0026#8217;t changed: I am still a big fan of all the principles like 80/20, GTD and Inbox Zero. In this post, I summarise my current process for staying organised and focused on what matters, and go into more detail about topics like personal vision, regular reviews and habits. Long Term plAlan (see what I did there?) There isn\u0026#8217;t much point in making progress if you don\u0026#8217;t know where you are trying to go. That is why I regularly set aside time to reflect on what I want my life to be like in the future. There are 3 ways in which I like to think about this: My life in 25 years A good way to come up with answers to this question is to imagine being on your deathbed and reflecting on a life well lived. What are the things that really matter in the end? For me, the answer to this question includes statements like \u0026#8220;Surrounded by friends and family\u0026#8221;, \u0026#8220;A life full of laughter\u0026#8221; and \u0026#8220;Jack of all trades, master of some\u0026#8221;. These are the types of things I try to keep in mind as the target end state for everything else that follows. My life in 5 years I am barely recognisable from the person I was 25 years ago. But 5 years ago me is pretty similar to the person I am now. 5 years is far enough away to be ambitious, but near enough to get into the detail. I find that it helps to be specific, as it gives me something concrete to aim for \u0026#8211; one big step en route to my 25-year vision. Visualising achieving it helps me validate that it is actually the direction I want to be going in. My answer to this question includes statements like \u0026#8220;3 day weekends every week or two. 1 week off every 3 months. No more burnout\u0026#8221; and \u0026#8220;Get outdoors a lot. Surf/swim/yoga regularly\u0026#8221;. I have about 7-8 statements in total. I am already doing most of the things on my list. I have plans to get to the others in the not-too-distant future. Chief amongst them is getting an electric car. I\u0026#8217;m thinking a Polestar 2 or an Ioniq 5. Let me know if you have an opinion on that! Unsurprising, visualisations are a powerful technique for articulating visions of any length of time. Collaging a vision board of images which represent what you want the future to look like is a technique I have found valuable. Goals These are the themes or pillars which I need to focus on in order to get where I want to go. For me, they are people, health, fun \u0026 experiences, impact, learning, security, career. I keep track of my achievements, ideas, priorities and plans under each of these headings, and organise my quarterly reviews around them. Reviews Reviews help me keep track of progress, reflect on my ambitions, and make more concrete plans for getting things done. Quarterly reviews My quarterly review template\nI have kept up with doing quarterly reviews for most of the past 6 years. The times when I have done this have felt more balanced and productive. It feels like a really healthy habit. In these reviews, I ask myself 6 questions: What went well What didn\u0026#8217;t go well What did I learn What did I say I\u0026#8217;d do vs what did I actually do My plan for next time What / who am I grateful for To prepare for this review, I review three things My long-term plAlan document (vision and goals) My calendar All of my weekly reviews from the last quarter The checklist I use for my weekly reviews\nWeekly reviews I usually do my weekly reviews over the weekend, though I usually update my weekly note throughout the week. My notes include: Notes, stories and learnings: these are often populated from my inbox, calendar and other notes I have created throughout the week Actions: these are things I decided this week that I need to do. Habits: these are all the new things I am trying to do once per week (eg. I am committed to doing a few hours of a coding project once per week). This doesn\u0026#8217;t include things that are already well-entrenched habits. Exercise: I try to do quite a lot of exercise every week. But I leave myself space and flexibility for rest days so that I don\u0026#8217;t become a slave to the home gym, and don\u0026#8217;t set my expectations of myself unreasonably high. Meeting my goal to exercise 5 days per week feels better than failing to hit a goal of 7 days per week. I keep my weekly reviews private. But I know a lot of good people who like to work in the open with their weeknotes: Neil Williams and Steve Messer first among them. That doesn\u0026#8217;t work for me though. I get quite anxious when I am writing for a public audience, and I want my personal reviews to be low-barrier and unfiltered. So instead, I like to keep my blogging focused on specific topics and keep my weekly reflections private. Though one strength of writing in the open is that you have the internet holding you to account to actually stick with the habit! The checklist I use for my weekly reviews\nWhy I gave up on daily reviews Daily notes or reviews are recommended by many. I have tried doing these, but I personally find it too hard to commit to doing one every day. I also find that if I miss a few days, I grow horrified at the empty templates in my daily notes folder and end up giving up on the whole thing. It\u0026#8217;s a habit I find too easy to fall out of when I miss a couple of days. For me, I have found it much easier to commit to doing something for 30 minutes once per week than for a few minutes every day. The best habit has to be one you can actually do and keep on doing. I am usually tired at the end of the day and am winding down. I can usually be found dosing off with some sci-fi or historical fiction as my girlfriend diligently does her daily review (which she does in a paper notebook. How very 19th century of her). Focusing on forming productive habits Habits help me get more done with minimum willpower because once doing something becomes a habit it just happens automatically (eg. brushing your teeth in the morning). A big part of my review process involves habit. That includes both regularly doing the reviews themselves, and the things which I use the reviews to try to get myself doing more of / more often. As well as the habits section in my weekly review of things I want to be doing weekly, I also have the following: Morning \u0026amp; evening routine These are things I do every day just after waking up and right before going to bed. For example, my morning includes things like drinking water as soon as I wake up, meditation and getting pestered by hungry cats. My evening routine includes things like reading before bed, setting my alarm to go off in a different bedroom to force me out of bed in time and you guessed it, feeding the cats. Recurring tasks I have a whole range of boring little tasks I need to do 1-2 times per week, fortnight or month. These range from watering plants to cleaning out the filters on the Dyson. I have set these up as recurring tasks, and I can see a live view of any that are due, overdue or upcoming in my tasks page. This page captures all tasks across all notes, with those that have a date or are tagged as important near the top. Reusable checklists For things I do often, I like to keep reusable checklists. Packing is a good example of one of these. Each time I do a trip I just untick everything on the list, and re-tick it when I\u0026#8217;m packed. As I change the list, I carry over the changes to the next time. The items at the top of my packing list\nSeparating work and play The eagle-eyed amongst you will remember that one of my goals is to separate out my work and personal life. I work a 4 day week at Climate Policy Radar which is awesome, and I try hard to minimise time spent working late into the evening. Separate profiles for work and life on Chrome. My work profile is too serious for a profile photo\nIt is hard to switch off properly when all my work notes are integrated with my personal ones, so I try hard to keep them separate. That is easy on a laptop or desktop, as I just have separate logins for work and life. It is a little bit harder on mobile though. All my work is done with tools like Notion, Linear and Slack (read more about how we use Notion and Linear to manage our product backlog). I have access to these apps on my phone, but they are disabled Friday-Sunday and during the evenings after 7 pm. I have work email on my phone, but I keep the Gmail app for my personal email only. I access the work email via a separate email client, which makes it easier to block on evenings and weekends. Check out my blog post on Make Time, Busy Bandwagon and Infinity Pools if you are interested in reading more about this topic. Other changes I have made List checkboxes vs personal Kanban I still use Kanban boards to keep track of things I am doing for work. My work-to-do list automatically integrates with tasks assigned to me by the team in Linear. I also still use it in my personal life, for things like books I\u0026#8217;ve read/want to read \u0026#8211; largely because I haven\u0026#8217;t bothered migrating this away from Trello yet. But I have moved away from keeping track of day-to-day personal life actions on a personal kanban. There are two reasons for this: Lots of the tasks I need to do day to day exist at very low fidelity. Too often this broke the work-in-progress limits on my kanban. The act of ticking things off a to-do list felt more suited to these types of small actions than moving them between columns on a Kanban board. Migrating from Trello and Evernote to Obsidian I was attracted to Obsidian for three main reasons: It offered a way of managing tasks and notes all in one place It was open source and infinitely customisable It enables you to build a knowledge graph of all your notes \u0026#8211; creating a personal brain The migration away from Trello and Obsidian was fairly painful, but I am a geeky type of person who enjoys that sort of thing more than most. I like that Obsidian is based on open formats, which should make it easier for me to move away from it in the future if I have to. Almost everything described in this post is done via Obsidian. I\u0026#8217;ll write a separate more detailed post about this another time. Top 10 I often find myself wasting hours of time worrying or thinking about things I shouldn\u0026#8217;t do. This ranges from worries about health and career direction to smaller issues like whether I can buy myself a new smartphone yet (and when I do which one I should buy). This is a waste of time and energy. To help me better focus, I have made a list called \u0026#8220;top 10\u0026#8221; of the things I like to worry about the most. For every item on this list, I have a note in Obsidian where I have articulated my plan for dealing with the thing. When I spot myself worrying about something on the list, I say \u0026#8220;Top 10\u0026#8221; to myself. I ask myself \u0026#8220;Is there new information which means I need to update my thinking in my top 10 list?\u0026#8221; If the answer is yes, I let myself think about it. Otherwise, I tell myself there\u0026#8217;s no point wasting my time overthinking things and I move on to something else. This is also not my invention \u0026#8211; I read it somewhere years ago but cannot remember where! Final note All the practices mentioned in this post work well for me, but I am far from perfect in my application of them. I fail at all of them some of the time. But I do stick with them most of the time. And when I do, I feel better for it. \u0026#8220;Don\u0026#8217;t let the perfect be the enemy of the good\u0026#8221; is one of my favourite quotes. Consistency is key to forming productive habits, but consistency looks different to different people at different times. Consistency looks different to different people at different times. Image source\n","permalink":"https://alaniswright.com/blog/personal-vision-regular-reviews-habits-obsidian-organised-focused/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  In 2018, I wrote a blog post which turned out to be one of my most popular: \u003ca href=\"https://alaniswright.com/blog/how-i-stay-organised-using-trello-kanban-gtd-and-inbox-zero/\"\u003eHow I stay organised using Trello, Kanban, GTD and Inbox Zero\u003c/a\u003e. A lot has changed in the past 6 years! Wunderlist is no more. Trello has been acquired by Atlassian. I am no longer using personal Kanban. And there\u0026#8217;s a lot that hasn\u0026#8217;t changed: I am still a big fan of all the principles like 80/20, GTD and Inbox Zero. In this post, I summarise my current process for staying organised and focused on what matters, and go into more detail about topics like personal vision, regular reviews and habits.\n\u003c/p\u003e","title":"Personal vision, regular reviews, habits and Obsidian. How I try to keep myself organised and focused"},{"content":" One of the best books I have read in the past decade is Make Time by Jake Knapp and John Zeratsky. The book explores techniques to help readers \u0026#8220;focus on what matters every day\u0026#8221;, and it has had a big influence on how I try to spend my time. This blog post covers the two concepts from this book that have been most useful to me: busy bandwagon and infinity pools. Make Time book image from Goodreads.\nBusy bandwagon Busy bandwagon refers to the tendency for us to always be busy and occupied with something. The authors argue it is important to make space for just being rather than forever striving to do more. This doesn\u0026#8217;t come naturally to me. I can be a bit of a workaholic and I find it hard to sit still. To get control of the busy bandwagon, I have consciously tried to build boundaries between my professional and personal life. This includes things like: separate personal and work accounts on my devices blocking access to work apps on my phone outside of work hours making sure I have at least 1 day per week and 1 week every few months where I take a proper break leaving plenty of space in my days for doing what comes to mind The most transformative change I have made to keep the busy bandwagon under control has been my mindfulness practice. I started in 2014 when I completed an 8 week mindfulness program. Mindfulness teaches you to live in the present moment rather than dwelling on the past or scheming about the future. So it is particularly useful for someone like me whose default state is to rush through life from one thing to the next without stopping to breathe. Since reading this book, I have meditated pretty much every day, which helps me be a bit more mindful as I go through the day. Taking this to the next level, I have heard people like Yuval Noah Harari and Rory Stewart say excellent things about 10-day Vipassana meditation retreats, but I haven\u0026#8217;t mustered up the courage to book onto one yet. 10 days of silence feels like a lot! Mindfulness book image from Goodreads\nInfinity pools Infinity pools refer to the dopamine-induced need most of us now have to always be scrolling through information, usually on our phones. I have often found myself scrolling away through apps like Instagram, Facebook, LinkedIn and Guardian News and watching the hours tick away. I don\u0026#8217;t want to delete these apps. It is important to keep up to date with the news and professional networks. Facebook is an excellent way to keep in touch with friends and access local community groups. And I don\u0026#8217;t want to completely give up making my life look better than it is on Instagram. So I have bought access to an app called Freedom that prevents me from accessing any of these apps other than for a couple of hours in the middle of the day (which is usually when I am busy enough to not fall into the infinity pool trap). It works across all my devices, which makes it much harder for me to cheat. The act of paying for the app also makes me a bit more committed to following through. I must admit, I do from time to time delete this app in order to do something urgent only to not install it again for a while. It takes a lot of practice to break the infinity pool habit. I can\u0026#8217;t honestly claim I have cracked it, but the time I spend infinitely scrolling has gone down a lot. I also subscribe to a weekly news magazine instead of refreshing the BBC homepage every few hours. Weekly is a good enough cadence for me to keep up with what is going on in the World. A weekly news magazine also has the time to go into far more depth into the issues of the week than a daily news publication. This is what I see when I try to access Instagram before 11 am or after 2 pm\nOther nuggets of wisdom from this book Some of my favourite quotes from Make Time: \u0026#8220;You create your own reality by choosing what you pay attention to\u0026#8221; \u0026#8220;Do not ask yourself what the world needs. Ask yourself what makes you come alive, and then go do that. Because what the world needs is people who have come alive.\u0026#8221; \u0026#8220;Make a list of the big things that matter in your life.\u0026nbsp; Choose the one most important thing. Rewrite the list in order of priority. Keep this list around to remind yourself of your one highest priority—and to break ties between two activities when you’re not sure how to spend your effort.\u0026#8221; \u0026#8220;Eat food. Not too much. Mostly plants.\u0026#8221; There are about 100 recommendations in this book, and I have only covered a few in this post. I definitely recommend reading Make Time if these types of topics are interesting to you. ","permalink":"https://alaniswright.com/blog/make-time-busy-bandwagon-infinity-pools/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  One of the best books I have read in the past decade is \u003ca href=\"https://www.goodreads.com/en/book/show/37880811\"\u003eMake Time\u003c/a\u003e by Jake Knapp and John Zeratsky. The book explores techniques to help readers \u0026#8220;focus on what matters every day\u0026#8221;, and it has had a big influence on how I try to spend my time. This blog post covers the two concepts from this book that have been most useful to me: busy bandwagon and infinity pools.\n\u003c/p\u003e","title":"Busy bandwagon and infinity pools – minimise these two things to make time for what matters"},{"content":" Working in an AI startup has its benefits. Chief among them is that I have spent a lot of time working with a small but talented group of people who have a great understanding of AI technology. I have been trying hard to absorb as much of that knowledge as I can along the way and to find ways to incorporate AI into some of my product management practices. This post summarises some of what I have learned. Before we start, here is Copilot Designer\u0026#8216;s response to the prompt: Generate an image of Alan Wright from Climate Policy Radar and AlanIsWright.com using AI to help him do product management work Copilot thinks I am an old man who likes to play with toy aeroplanes…\n8 ways I am using AI to help me be a better product manager 1 – Postcards from future users \u0026amp; personas Taking inspiration from Working Backwards, one of my preferred methods for articulating a vision for products and features is through using postcards from future users. These are brief statements, penned by imagined users months or years into the future, illustrating in their own words how our tools have been of help to them. The aim is to help the team align on a shared vision of the impact their work has on our target users. These statements should be written in the style of the persona, be engaging to read, and help generate excitement within the team.\nCreative and inspiring writing is not my strong suit. My attempts at writing this content myself were not only time-consuming but also a bit dull for others to read. However, creative writing is something that generative AI models like ChatGPT excel at. Here is a prompt that I have utilised to generate postcards from future users:\nYou are . Write a postcard explaining how this new feature from Climate Policy Radar has made your job easier. \u0026#8221; Information about is below:\nThe first drafts of the personas were also created using AI tools. Note that these needed far more editing than the postcards from the future, as they had a tendency to include details that didn’t align with what I had observed in user research. However, the writing process was far quicker and better than if I had done it myself. Here is an example prompt:\nYou are an expert in user research. Write a persona using the information below. Your answer should be under 4 headings: motivation, goals, pain points, tools.\n\u0026nbsp; 2 – Solution ideas Generative AI tools excel at generating ideas. Below is a prompt I like to use when first starting to ideate how he might solve problems. I ask for the URL so it is easy for me to check it out myself:\nYou are an expert product manager. Our product is What are the best solutions that allow a user to feed back on the quality of content in a digital product? For each example, list the URLs of some popular products that use that solution. 3 – Risky assumptions Premortems help us identify and reduce risks before they happen. But they can be time-consuming to do, and too often get deprioritized in favour of delivery.\nIncreasingly, I am using ChatGPT to do premortems for me. ChatGPT has been trained on a huge volume of literature. In amongst that is a whole bunch of content from other product teams about how and why features have gone wrong for them in the past.\nBelow is a prompt I like to use to help me identify the types of risks we need to tackle through product discovery:\nYou are an expert product manager. We are building a feature that enables users to thumbs up or thumbs down a search result. Tell me 20 ways in which this feature could fail. Which are the highest impact and most likely to occur? 4 – Product requirements There is a wealth of useful data on the internet about how others have previously solved problems similar to ours. So when drafting requirements for more generic new features, I try to avoid reinventing the wheel and utilise prompts like the one below:\nYou are an expert product manager. Write a product requirements document for a feature that enables a user to give a thumbs up or thumbs down response to a search result.\nLess is more in product requirements. One of the arts of good product management is being able to distil long lists of requirements down to the smallest number expressed in the simplest way. This enables the team to deliver value at pace. I like to take what ChatGPT gives me as a first draft. This is much faster than me trying to draft it from scratch, and ChatGPT usually remembers things that I would have forgotten. But this is always followed by me hacking away at unnecessary requirements or detail.\nAfter I have a first draft, I like to follow up with the question:\u0026nbsp; Tell me 20 weaknesses of the above product requirements document.\u0026nbsp; This helps me spot any areas which might have been missed. 5 – Rewriting content It might surprise readers of this blog to learn that I am not the strongest user of the English language. I have always struggled with grammar \u0026#8211; my unedited content has upset many a communications person in roles past and present!\nRather than going back to school and learning how grammar works, I am using AI tools to double-check important content that I write.\nFor years, Grammarly has been my go-to tool for proofreading. I like that it offers suggestions that I can accept and reject on a case-by-case basis. I dislike that a lot of its features are behind a paywall, yet these features are visually prominent in the user interface and hard to ignore.\nAfter watching our founder use ChatGPT to proofread and improve content that had already been checked by Grammarly, I am increasingly using ChatGPT instead. Overall I have found the results to be better, probably in part because I have a GPT4 API key while I only have the free subscription to Grammarly.\u0026nbsp; A disadvantage of using ChatGPT is that there is always a risk of it changing the meaning or context of content without me realising it, especially as changes can’t be explicitly tracked and accepted. So proofreading is essential. But then again, proofreading is always essential, so it doesn’t add any extra stages to the process.\nThe screenshot below shows what this section of the blog looked like before I used GPT to fix it. See if you can spot the difference. I use the GPT for Sheets and Docs plugin alongside my GPT4 API key in Google Docs and Sheets\n6 – Transcribing meetings Voice recognition technology has seen significant improvements in recent years. Two products that I have used to transcribe meetings are Read.AI and Otter.AI. Both are accurate and can be really useful to quickly read through the notes from important meetings that I wasn’t able to attend or to take detailed notes during user interviews where I don’t have a note-taker present.\nRecording voice notes is another big benefit from the increase in voice recognition and transcription accuracy. I am alternating between AudioPen and Google Voice Recorder for this. It’s a handy way to be able to take long notes on the go. 7 – Writing SQL / Python code AI has made it far easier for me to do simple technical tasks myself that I might previously have had to ask an engineer or data scientist to help with or spent hours trying to figure out. I use Cursor as my IDE, and combined with my GPT4 API key, it writes and reviews code based on natural language prompts. This has enabled me to do things like find duplicates in our dataset, assess our data quality, analyse survey results, and write queries to understand how new features are performing \u0026#8211; without distracting the team. The faster progress that AI has enabled has also kept me motivated to keep developing my technical skills. Using GPT4 in the Cursor IDE to to help me write some Python\n8 – As a general replacement for search engines Search engines like Bing and Google are great for finding web pages that answer my questions. These are still my go-to tools for when I want to do a thorough search and evaluate all the source content myself.\nThrough featured snippets and knowledge panels, search engines also try to surface content from the highest-ranking web pages that they think answer my questions. However, this is a relatively small part of the search results \u0026#8211; there are usually a lot of paid ads competing for my attention.\nIncreasingly, I am using Perplexity instead of traditional search engines for four reasons: It better understands the questions I am asking by asking clarifying questions when necessary. It is up to date. It searches the internet and summarises key information from the top-ranked articles. It cites the sources it uses, making it easy for me to verify results or do more of my research. The user interface is clear and uncluttered. An example of a Perplexity response. Most of the time, this is more useful than what traditional search engines provide 4 ways I am not using AI 1 – To do anything more than a draft AI models can sometimes make mistakes, misunderstand context, and fabricate content. We have all seen the pictures of people with six fingers and three legs, or heard about cases like the lawyers who got fined for submitting fake citations they were given by ChatGPT.\nI don’t know who said this first, but there’s a good quote going around about AI being like having 1,000 interns. I like this analogy because it illustrates the huge potential to get work done to a fairly decent standard. But as with interns, with AI, it is wise to double-check its work. This usually means: Edit it down a bit to focus on the most important details. AI can be verbose. Saying the same thing with fewer words makes it easier for people to understand each other. Spot any areas that might have been missed or underemphasized. This is where expert knowledge comes in. With 15 years of experience managing digital products, I have a good sense of when AI is saying something that isn\u0026#8217;t quite right about product management. I am much less capable of challenging the outputs of an AI that is writing a Python query. Check the source data myself for anything that doesn’t sound quite right. This is why I like tools like Perplexity that make it easy for me to access the source data. 2 – Writing notes for important meetings Tools like Read.AI, Otter.AI, and Notion all offer meeting summarization functionality. These can be useful for getting a sense of what was discussed. Despite this, I still summarise important meetings the old-fashioned way for two main reasons: AI summaries have a harder time than I do of distinguishing signal from noise. All too often they overemphasise irrelevant information and play down or ignore completely the important details. They also tend to be verbose, and I have seen them get important details wrong. I often use the process of writing meeting notes as a way to facilitate meetings. The process of recording actions, decisions, and questions is a collaborative one that shapes the meeting when done in real time. For low-stakes meetings where I wouldn’t usually take notes or am unable to attend at all, summaries are better than nothing. But they are not yet at the stage where they add much value for me otherwise. 3 – Analysing user research findings I have seen a few blog posts from people who have been using AI to summarise the results from user interviews and usability tests. This isn’t something I have found much value in so far. Partly this is because of the first point above: there is too much noise in the summary and important details are often missing. It is also because: A lot of the value I get from the research process is in the synthesis. Most user research conversations I have are immediately followed by a chat with the other team members involved. AI summaries often get generated too late to be used for this conversation. And even when they are generated in time, I haven’t seen them add that much value. A lot of the insights from user research are not captured in transcripts. Facial expressions, pauses, tone of voice, and whatever the user is sharing on their screen all contain useful information which AI summaries will miss. 4 – Writing blog posts Don’t worry, dear reader. This blog post is an original man-made work of art from me (with only a little bit of help from ChatGPT to put capital letters and hyphens in the right place). In case you\u0026#8217;re wondering if AI could have done better. below is an AI-generated version of this post and the prompt I used to make it. You are an expert product manager. Write a blog post about how AI can help product managers to be better at product management. Write in the writing style of alaniswright.com Title: Harnessing the Power of AI in Product Management: A Game-Changer for Product Managers\nProduct management is an ever-evolving discipline that requires constant adaptability and learning. As the technology landscape continues to shift, product managers need to stay ahead of the curve, leveraging the latest advancements to streamline their processes, enhance product development, and deliver superior customer experiences. One such technological revolution that is transforming the product management landscape is Artificial Intelligence (AI).\nAI has become an integral part of our everyday lives, from virtual assistants like Siri and Alexa to recommendation engines on Netflix and Amazon. But its potential extends far beyond these consumer-facing applications. AI has the power to revolutionize product management, helping product managers become more efficient, strategic, and customer-centric. Let\u0026#8217;s delve into how.\n1. Enhanced Decision-Making\nAI can process vast amounts of data in real-time, providing product managers with valuable insights that would otherwise take weeks or months to compile manually. AI-driven analytics can identify trends, predict customer behavior, and highlight potential issues before they become significant problems. This data-driven approach empowers product managers to make more informed decisions, reducing risk and driving product success.\n2. Streamlined Processes\nAI can automate routine tasks, freeing up product managers to focus on more strategic aspects of their role. From tracking product performance metrics to managing stakeholder communication, AI can handle a wide range of administrative tasks, increasing efficiency and productivity. It also reduces the risk of human error, ensuring more accurate and reliable outcomes.\n3. Personalized Customer Experiences\nAI’s ability to analyze vast amounts of data also enables it to deliver highly personalized experiences. By understanding individual user behavior, preferences, and needs, AI can help product managers tailor products to meet the unique needs of each customer. This level of personalization can significantly enhance customer satisfaction and loyalty, driving long-term product success.\n4. Predictive Analytics\nAI\u0026#8217;s predictive capabilities are a game-changer for product managers. By analyzing historical data, AI can predict future trends, customer behavior, and potential issues. This foresight allows product managers to proactively address potential problems, seize opportunities, and stay ahead of the competition.\n5. Improved Product Testing\nAI can also streamline product testing, using machine learning algorithms to identify and correct bugs more quickly and efficiently than traditional methods. This not only speeds up the testing process but also ensures a higher-quality end product.\n6. Enhanced Collaboration\nAI can facilitate better collaboration among teams by providing a centralized platform for sharing information, tracking progress, and managing tasks. This can improve coordination, reduce misunderstandings, and ensure everyone is on the same page.\nIn conclusion, AI is a powerful tool that can significantly enhance product management. By leveraging AI, product managers can make more informed decisions, streamline their processes, deliver personalized customer experiences, and stay ahead of the competition. However, as with any technology, it\u0026#8217;s essential to use AI responsibly, ensuring it aligns with your product strategy and adds value to your customers.\nEmbracing AI in product management is no longer an option; it\u0026#8217;s a necessity. As product managers, let\u0026#8217;s harness the power of AI to drive product success and deliver exceptional customer experiences. After all, in the world of product management, staying ahead of the curve is not just about survival; it\u0026#8217;s about thriving in an ever-changing landscape.\u0026nbsp; End notes Thanks for reading! I want to finish by saying a big thanks to Henry Franks, Michal Nachmany, Kalyan Dutia, Harrison Pim, and Matyas Juhasz. Many of the techniques I have mentioned in this post have been born from conversations with you all! Check out 3 more recent AI related posts I have written: Prompt engineering as a product manager, AI product management in high stakes domains and 6 ways I like to use ChatGPT Other AI blog posts written by me Google AI Pro: Image Editing, Deep Research and Fantasy Premier League AI prompt engineering as a product manager 6 ways I like to use ChatGPT AI product management in high stakes domains ","permalink":"https://alaniswright.com/blog/8-ways-i-am-using-ai-to-help-me-be-a-better-product-manager-4-ways-i-am-not/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  Working in an AI startup has its benefits. Chief among them is that I have spent a lot of time working with a small but talented group of people who have a great understanding of AI technology. I have been trying hard to absorb as much of that knowledge as I can along the way and to find ways to incorporate AI into some of my product management practices. This post summarises some of what I have learned. \n\u003c/p\u003e","title":"8 ways I am using AI to help me be a better product manager (and 4 ways I am not)"},{"content":" Roadmaps, delivery plans, timelines and dependency maps are all artefacts that people use in different and overlapping ways. In this post, I describe my interpretation of what each of these artefacts are, how I like to use them when working with product teams and explain how the Civilization 6 Tech Tree can be a source of inspiration when planning ahead. Roadmap Vision describes the future we are trying to create. The strategy describes our approach to achieving the vision. The roadmap visualises the plan to achieve the product strategy. At a high level, it should show the problems we plan to solve, in what order and over what timeframe. The target audience for a roadmap is all stakeholders, customers and users of the product. For public-facing products, I like to have a public-facing roadmap. One of the main things I learnt from working at the Government Digital Service was that making things open makes them better. A public-facing roadmap gives everyone a chance to understand your priorities and provide feedback. Even if no users ever look at it, the process of creating and maintaining it forces me to articulate what we are doing to a wider audience, which is something that all product managers have to be good at. My preferred format is the now, next, later roadmap. Here\u0026#8217;s why: 1. Just enough information for most. Most people don\u0026#8217;t need to see a highly detailed plan. They just want a rough idea of what changes are coming in the short, medium and long term. This artefact meets the information needs of the majority concisely and simply. 2. Handles uncertainty well. Software is inherently complex and uncertain. It is hard to accurately predict how long work will take until work is scoped and estimated. Planning too far ahead is usually a very inefficient way to work, and often offers false certainty. Now, next and later gives the reader a sense of priority, timeframe and ambition, without the team wasting too much effort on providing false certainty in long term plans. 3. Easy to maintain. This roadmap is done to a level of accuracy that most software teams can easily provide. More granular detail can be provided for items in Now as these are things that engineers are working in now. Items in Later can and should be kept at a much higher level. Not having specific dates on things avoids awkward conversations when those dates inevitably need to change. A snapshot of our public product roadmap at Climate Policy Radar\nHow to define now, next and later? In the Climate Policy Radar roadmap, I am using these definitions which are inspired by Prodpad. I am not using a \u0026#8216;not doing\u0026#8216; column in my roadmap at present, but they can be helpful, especially when looking over a defined time period (eg. 6 months of 1 year). A good product strategy answers the question \u0026#8220;What are the few things we will focus on and the many things we won\u0026#8217;t\u0026#8221;. Being explicit about what you are not doing helps create clarity and focus. Delivery plan Like roadmaps, delivery plans show us the problems that the team is solving, in what order and over what timeframe. In addition, they: focus on specific tasks or outputs (as well as problems to solve or outcomes) get more specific on who will be doing the work, by when and in what order (much more specific than now, next and later) Delivery plans are primarily targeted at an internal audience: the people who are building the product, and the leaders who are overseeing that work. Their main purpose is to help the organisation plan and deliver work. Recently I have been working with delivery plans at two different levels: Tools like Linear and Jira can automatically generate delivery plans and timelines\nShorter-term iteration plans from teams Teams working in sprints will usually have at least the next few weeks of work mapped out in detail in tools like Linear or Jira. For work that\u0026#8217;s in flight or starting soon, requirements for new features or functionality will be broken down into specific estimated tasks. Other work like bugs, support, technical rework or chores that would rarely make it into a roadmap are tracked here. In an ideal world, non-product work such as recruitment or learning \u0026 development would be tracked here too. With all the work tracked in one place and estimated, tools like Linear and Jira will help teams estimate when the work will get done based on their prior delivery velocity and automatically generate project plans or Gantt charts. Tools like these give us much higher levels of accuracy in predicting what work will get done in the next 1-4 weeks, and when new work will be ready to start. A short-term view like this helps us get into the details of things like release planning, go-to-market planning, stakeholder management and planning ahead for activities like kicking off new work and scheduling user research. In Linear, you can create specific views of work related to different sets of features that cross team boundaries, such as our work to bring in new datasets. This automatically creates a delivery plan that can be used by the cross-team working group that meets to align all data in work every fortnight. Humans are bad at estimating software projects, so more often than not, work ends up taking longer than forecast (here is a technical explanation of why). To help counteract this, I like to encourage teams to add placeholder tasks to represent unknowns that could blow up and slow things down. As work progresses, these can be marked as done. Higher-level internal timeline Planning software work months and years in advance is very, very hard to do accurately. But not planning at all hides useful information about what we hope to achieve by when, what order things come and what we think is achievable. For this reason, I like to maintain a high-level internal product timeline. It communicates at a high level where we think we will get to in the months and years to come. It includes information such as contracts coming to an end, legal deadlines, dependencies and strategic milestones that we don\u0026#8217;t want to communicate externally but still want to aim for internally. This information helps teams to take a longer-term view where beneficial to do so. However, because it tries to look further into the future it is inherently a lot less accurate. It is important that this is understood by everyone. Dependency map Best game ever! Also a better than real World example of how a dependency map can be useful\nAnyone who has played one of Sid Meir\u0026#8217;s Civilization games will be familiar with the technology tree. New technologies unlock new capabilities (eg. units, buildings), and enable more advanced technologies to be researched in the future. The tech tree visualises all of these technologies, capabilities and dependencies on a visual map. Users can use the map to work backwards from specific capabilities they want to unlock and figure out which technologies they need to research to make that happen. Dependencies are often mapped in delivery plans or timelines. Even so, I often maintain a standalone dependency map which focuses exclusively on dependencies. There are a few reasons why: 1.. Supporting strategic decision-making. Just like in a Civilization game, decision-makers can work backwards from longer-term ambitions and get a sense of the problems they need to solve to achieve them. In Civilization, you might face a choice between racing to discover gunpowder or developing ships which can navigate the great blue seas. There is usually a choice between doing everything slowly versus a smaller number of things faster, which is essentially a choice between having a clear and focused strategy or not. A dependency map visualises what we know about the likely costs of achieving a goal, and helps people to understand the trade-offs. It is particularly helpful when combined with some idea of how big or complex each item on the dependency map is. 2.. Supporting cross-team planning. In all big organisations where I have worked, there has been a regular (usually fortnightly) conversation about dependencies with a representative of each team. In that meeting, we review the dependency map and ask ourselves two questions. Question 1: are there any new dependencies we need to manage? Unlike in a video game, the future in real life is far from certain. New dependencies are discovered as we go along. Question 2: are any of these dependencies likely to block or impede us? If so, how do we stop that from happening? This allows us to keep up our delivery momentum and flag any delays or risks early. 3.. Low effort to maintain. There should not be too many dependencies to map and manage in product development. If there are, then that\u0026#8217;s a sign of a much bigger problem. 15-30 minutes every couple of weeks is usually enough to maintain an accurate dependency map. Why so many artefacts? All of these artefacts are solving a similar set of problems: communicating work to do, timelines and priorities. It might seem unnecessary to have 3-4 different artefacts doing the same thing. After all, maintaining multiple artefacts can be time-consuming. However, tools that do lots of things have a tendency to do all of them badly. Trying to combine all of these things into just 1-2 artefacts means each of those artefacts becomes more complex. More complex artefacts are harder for people to understand, which can lead to misalignment and misunderstanding, which can lead to costly mistakes. Personally, I find the benefit of improved team/stakeholder alignment generally outweighs the cost of maintaining multiple smaller artefacts. That said, I am always looking for ways to feed two birds with one scone where possible, and all of the above aren\u0026#8217;t always necessary on every team. ","permalink":"https://alaniswright.com/blog/roadmaps-delivery-plans-timelines-dependency-maps-civilization-product-teams/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  Roadmaps, delivery plans, timelines and dependency maps are all artefacts that people use in different and overlapping ways. In this post, I describe my interpretation of what each of these artefacts are, how I like to use them when working with product teams and explain how the Civilization 6 Tech Tree can be a source of inspiration when planning ahead.\n\u003c/p\u003e\n\u003ch3 class=\"wp-block-heading\" id=\"roadmap\"\u003eRoadmap\u003c/h3\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  Vision describes the future we are trying to create. The strategy describes our approach to achieving the vision. The roadmap visualises the plan to achieve the product strategy. At a high level, it should show the problems we plan to solve, in what order and over what timeframe.\n\u003c/p\u003e","title":"Roadmaps, delivery plans, timelines and the Civilization 6 technology tree – how I like to use these artefacts when working with product teams"},{"content":" I have been working with teams on digital products \u0026 services for 15 years in a combination of product, program and delivery manager roles. Throughout that time, I have always been a bit frustrated by how little I know about the underlying technologies that power the web. I don\u0026#8217;t come from a computer science background, and despite many aborted attempts to learn to code, historically I have struggled to make as much progress as I would like. However, over the past few years, I have started to succeed a bit more in my goal of becoming a more technical product manager. In this blog post, I talk about why I am trying to improve my technical knowledge and the ways of learning that have worked best for me. Why does a product manager need technical knowledge? Technical knowledge isn\u0026#8217;t a must-have for most product managers. A little knowledge can even be a dangerous thing if used incorrectly. Product managers who overconfidently try to make technical decisions on behalf of their engineers risk both making the wrong decision and disempowering their team at the same time. That said, I think becoming more technical has made me a better product manager. As a PM, I need to balance user/business value, usability and technical viability when I make decisions. Understanding the domain helps me make better decisions, faster. As a PM, I need to work with engineers every day. Sometimes I even manage products that engineers use. Building my technical skillset helps me to better empathise with engineers and data scientists, both as colleagues and users. For me, there is a big difference between knowing something in theory and knowing it because I\u0026#8217;ve done it a bit myself. Things like Jupyter Notebooks, APIs and HuggingFace are much easier to understand now that I have used them. As a PM, I need to understand our data: both product/user metrics and the data that we present to users in our products. Better understanding my team\u0026#8217;s data and how to work with data in general has given me a much richer understanding of the products I manage, and the role of the data scientists, analysts and engineers I work with. My technical background Despite my father\u0026#8217;s best efforts to get me into building software as a kid, it never really stuck. I remember trying to follow tutorials on Visual Basic back in the 90s and finding it far less accessible and certainly less interesting than football and video games. I studied economics, politics and international relations at school and university, and my technical skills didn\u0026#8217;t extend far beyond spreadsheets and trying to get PC games to work properly. Before University I started to get into graphic design and email marketing. After leaving University, I found myself working with a charity in Cambodia. I started learning web design there when I built a basic static charity website using HTML and CSS. This opened up quite a few doors for me, and I built quite a few other basic sites myself over the next couple of years. However, the advent of content management systems like WordPress and my move into more of a digital team management role meant I didn\u0026#8217;t write any code for a while. Ways of learning that have worked for me Blogs I follow One of the best blogs I have found is Technically. They describe themselves as \u0026#8220;a knowledge base for\u0026nbsp;learning about software concepts\u0026#8221;. It is aimed at product managers and other non-technical roles who want to understand software and work better with developers. To date, I have been too cheap to pay the $8 per month subscription, but I am signed up to the mailing list and have found some of the free articles on topics like \u0026#8220;What\u0026#8217;s web scraping\u0026#8221; and \u0026#8220;What\u0026#8217;s a data science notebook\u0026#8221; very informative. In some very theoretical future non-busy month, I imagine myself paying for a one-month subscription and reading everything I can. Other than Technically, I tend to just research specific topics as and when they come up as something I need to understand. I would have done that in previous years by Googling or searching for a Reddit thread where users recommend the best learning resources. But nowadays, I tend to start by asking ChatGPT or Gemini. Online courses In recent years, there has been an explosion in resources that help people learn computer science. With time, these have become noticeably more accessible. Two of the courses I have found most useful are: CS50: Introduction to Computer Science by Harvard. I audited this course a few years ago. The lectures gave me a good overview of computer science, and the exercises gave me a chance to explore a wide variety of languages and learn about different levels of abstraction in software. Data Scientist: NLP Specialist Career Path by CodeAcademy. I started doing this course when I joined Climate Policy Radar (a climate tech startup that works with AI, NLP and data science). It took almost 18 months to complete. It gave me a very broad introduction to the tools and techniques that data scientists and analysts use. The big benefit of doing these courses is that I am much more capable of keeping up with technical conversations and can make more informed decisions with my team. There is obviously still a huge gap in capability between me and even the most junior data scientist or software engineer. This certificate licenses me to make jokes with the data scientists about being one of them now\nUse it or lose it These aren\u0026#8217;t the only courses I have done. In years gone by, I have on multiple occasions spent months doing online coding courses, only to completely ignore the topic for months or years when work gets busy or something else comes up in life. Part of the reason I have found these most recent courses more useful is that the courses are getting better. But the main reason why I have stuck with it is that I have turned technical learning into a regular habit. When it comes to learning and retaining things, I have found you need to use it or lose it. This has been made much easier by us introducing a 4-day work week at work, which gave me the space to complete the course. Since I finished, I have been using a chunk of what would have been my 5th work day to focus on my hobby projects. Doing projects that help my team Doing projects is a great way to learn a new skill. I have taken on a couple of projects for my team in the past year: exploring our data quality metrics. When we first got access to data on the quality of our parsed text data, I spent a week exploring it myself and shared the findings at show \u0026 tell. Since then, the real data scientists have taken it over, thrown away my work and built something a whole lot better. However, the initial learnings were useful, both for me as a learning experience and for the insights I generated for the team detecting potential duplicates in the dataset. This is a problem that one of our data partners raised with us. I spent a few half days exploring this one myself, developing a pretty reliable way of detecting potential duplicates and presenting them in a form that makes it easy for our admins to check Doing projects that are useful to my team has three main benefits: it helps me learn about our data and technology. Whilst doing both of these projects, I spotted issues with our data and user experience, which have found their way onto our backlog as problems we need to solve. Structured data users are one of our main user groups, so I have also gained a first-hand experience of the journey they go on in trying to use our data it\u0026#8217;s useful to others, which gives me a sense of purpose and makes it easier to stay motivated. Presenting findings at Show \u0026 Tell that others find insightful and providing a partner with a tool which makes their life easier were both good experiences it means the team takes a bit of an interest in what I am doing. They give me feedback on my approach, review my code and help me out when I get stuck. Working with other people is more fun than being on your own, and it helps me get better Next up for me is: using all the various NLP and ML techniques I have learnt in some data analysis projects on our corpus. I need to go back and use some of the techniques I learnt from CodeAcademy in real life, otherwise, I am going to forget them be able to make basic content changes to our app. This has the double benefit of helping me understand our deployment process, and not having to waste our developer\u0026#8217;s time on small text changes to learn to build and deploy a basic app using FastAPI. This is the main Python framework we use. I think this project will give me a deeper understanding of how our backend works. It\u0026#8217;ll also mitigate the risk of engineers getting jealous about the amount of quality time I\u0026#8217;m spending learning data science 😉 Learning something = being able to explain it to someone A few weeks ago I went on a week-long work trip about generative AI. On the outbound flight, our lead data scientist explained to me what retrieval augmented generation was. I wrote up some notes, explained it back to him, and he corrected me where I wasn\u0026#8217;t quite right. In the 72 hours that followed, I explained retrieval augmented generation to other people about 20 times per day. This example neatly illustrates the 3 step process I go through when trying to learn technical concepts: try to understand the thing. I either go and read a bunch of articles, watch some YouTube videos or ask an engineer to explain it to me. Asking engineers to explain things is one of my favourite methods. Asking engineers to show me how the data pipeline runs or walk me through how they deploy a simple feature end-to-end has both been hugely educational and helped me understand the product value in improving and automating those processes explain it to someone who knows what it is. This might be in a conversation or in writing. I sometimes write glossary entries in our internal wiki for technical concepts I am trying to learn, then ask one of the tech leads to mark my work. Another technique I am increasingly using is trying to draw things. I find that if I can draw a little diagram to explain a thing, then it\u0026#8217;s not only easier to communicate, but I feel like my understanding of the concept is stronger find excuses to repeat myself. As the person who keeps multiple teams and partners in sync, I am usually not short of opportunities to practice explaining things. My very patient girlfriend is also kind enough to listen to me from time to time. If I understand something well enough to explain it to someone, and can still remember how to explain it again a few weeks later, then I will probably remember it Assistance from AI assistants I find it much easier to understand code that others have written than I do to create code from scratch. I find it much easier to explain the steps needed to make an algorithm work in plain English than I do to implement that in code. I use Cursor as my IDE (integrated development environment. This is an app that techies like me use for writing code). Cursor markets themselves as \u0026#8220;… the\u0026nbsp;IDE\u0026nbsp;of the future, built for pair-programming with Powerful AI.\u0026#8221; I use my GPT4 API key in Cursor. It helps me in two main areas: I can ask it to write code for me based on natural language prompts I can ask it to review the code I have written and suggest improvements or solutions to bugs If my ambition was to become a full-time engineer, I would be more wary about relying on AI assistance as a beginner. As a professional, it\u0026#8217;s important to have an excellent grasp of your trade from the basics upwards. But despite some friendly banter with the team about me becoming a data scientist, my goal isn\u0026#8217;t to be a technologist full-time. Product management is my thing. I am learning more about data and software out of personal and professional curiosity, and so that I can better communicate with technical teams and empathise with technical users. As someone who can only commit to doing this for less than 10 hours per week (a lot less when the sun is shining), if I tried to do this the hard way, I would make very slow progress. My progress might be so slow that I become bored or disheartened, and give up on the whole enterprise. Using Cursor has helped me make progress faster, which has kept everything interesting, meaning that I have kept up the habit and covered a wide variety of areas in a short space of time. And I have got a lot better at prompt engineering \u0026#8211; one of the biggest technical skills everyone will need for the future. Tools like ChatGPT are only getting better as time goes on, so as long as I keep making an effort to understand the solutions that AI assistants suggest, I think the benefits far outweigh the costs. Was this all worth it? I am pretty chuffed with the progress I have made this past couple of years, and not just because it has made me a better product manager. It has also been quite fun to learn more about the technologies that I have been working with for pretty much all of my working life. It is nice that I know a bit more about how things work, and to be more capable of solving problems myself when the need arises. I\u0026#8217;m excited to think about what I might be capable of in a couple of years if I keep up the habit, which is something I have every intention of doing. ","permalink":"https://alaniswright.com/blog/becoming-a-more-technical-product-manager/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  I have been working with teams on digital products \u0026 services for 15 years in a combination of product, program and delivery manager roles. Throughout that time, I have always been a bit frustrated by how little I know about the underlying technologies that power the web. I don\u0026#8217;t come from a computer science background, and despite many aborted attempts to learn to code, historically I have struggled to make as much progress as I would like.\n\u003c/p\u003e","title":"Becoming a more technical product manager"},{"content":" This post describes the simple approach we have settled on to keep track of our work at Climate Policy Radar: actions on Linear and documentation on Notion. How we use Linear Why we like Linear Linear prides itself on being a simple alternative to larger more complex task management systems like Jira. Their method is to offer a simple tool that doesn\u0026#8217;t have all the bells and whistles of some of the bigger players. Users need to accept the constraints that come with that. But if your ways of working align with the \u0026#8220;Linear way\u0026#8221;, then you get the benefits of a super-fast tool that is easy to use. No features are missing in Linear that anyone on our team feels are must-haves, so it\u0026#8217;s an easy trade-off for us. Below is a description of some of the key features of Linear and how we use them. Teams Tasks that need doing are tracked as issues in Linear. All issues must belong to a team, and teams can have different permission levels. We have a team for each product team and one for the whole organisation. Everyone has access to these. Senior leadership also has a private team that only they can access. Some individuals also have private teams to track individual work (eg. learning and development), though most work is tracked in teams that are open to everyone to see. Projects We use Linear\u0026#8217;s project functionality to keep track of each project (bet/initiative/backlog item) we are working on. Projects can cross team boundaries. Examples of projects Powering the climate-laws.org domain Launching GST1.org at the Bonn Climate Conference Developing our passage match translation functionality Projects can be used to group related work. When done, the project can be marked as complete and hidden from view. We make extensive use of the milestone functionality in Linear. Milestones represent different stages in a project’s lifecycle and help us organise work within projects. Usually, this means that issues for the next milestone are well defined, and exist as placeholders only for future projects. Views Team members can set up views in Linear to allow them to see all of their tasks across all of their teams in one place. I have a view called Plalan (my old GOV.UK nickname). This view shows me: all tasks assigned to me all tasks tagged as needing product manager input all tasks on my personal board Similar views have been set up so that people can see all work via any combination of label, project or people filters. The main view I use to keep track of all my work in Linear\nWorkflow stages and labels Linear enables each team to have a bespoke workflow. If teams add in new stages or rename existing stages, then when people try to view their tasks across teams they will see too many columns. This is why we have decided that each team should use a consistent workflow. For now, all teams use the following workflow: Triage \u0026#8211; add any new ideas here for a team lead to review. Triage is not visible in normal view. In general, items move out of triage with the agreement and understanding of the team. \u0026nbsp;Backlog \u0026#8211; jobs that need doing that are not urgent / priority \u0026nbsp;Priority \u0026#8211; jobs that have been prioritised to do next \u0026nbsp;In progress \u0026#8211; jobs someone is working on \u0026nbsp;In review \u0026#8211; jobs that have been done, but need someone to review them before they can be confirmed as done \u0026nbsp;Blocked \u0026#8211; the team cannot work on this task because of something out of their control blocking them \u0026nbsp;Done \u0026#8211; jobs that are done \u0026nbsp;Cancelled \u0026#8211; jobs that we aren’t doing anymore Labels Labels are tags assigned to each issue. Labels can exist at the team or workspace level. Again, the benefit of using labels consistently across teams is that it is easier for people to see their work across teams. So when we see multiple teams using the same label, we elevate it to become a workspace label. Teams can apply whatever extra labels they like. These will not be visible to other teams, but they will be visible on any views created where linear issues across multiple teams Any labels created for one-off usage will eventually be deleted to avoid clutter. This means it won’t be possible to refer back to the work in the future grouped by that label, as the label will be gone. So we prefer grouping issues into projects or under a parent issue to using temporary labels. How we use Notion Projects database Each project in Linear links to an entry in our Notion Projects database. This database contains all the work that we might do that might deliver impact to our users, including product improvements or projects for partners. Once prioritised, projects should include: hypothesis statement describing what we are doing and the impact we expect it to have (always at the top of the page) project brief, including problem statement, goals, and any early thoughts around possible options, risks and delivery plans link to designs, whimsical boards, etc all documentation, specifications, architectural decisions, notes and meeting notes (this is done via a linked view of the Notes database) Before being prioritised, bets contain much less structured information. It is more of a dumping ground for ideas. This includes feature ideas that aren’t ready to make it onto a linear backlog, but that the team have started thinking about (eg. multilingual, expanding outside of National law and policy, etc). This content is filtered out by default, so it gives people a place to dump ideas, articles and thoughts without cluttering the views in Linear and Notion that we use day to day. Linear has some project update functionality which looks strong, but we have decided against using it so that we can keep all documentation in one place in Notion. Notes database Another Notion database we use a lot is the Notes database. We use the Notes database for all documentation, research or meeting notes. It is much better to have all these things together in one database, as it makes it easy for us to group them in an easy-to-find way. You can see all notes that related to a project on the projects page, all notes tagged to a person on their person page, and all notes relating to a functional area like \u0026#8220;policy\u0026#8221; or \u0026#8220;frontend\u0026#8221; on their page. You can easily create new notes with all the relevant metadata applied by creating the note in one of those places. To make notes easier to fund and file, all notes include metadata on the: team members involved in the note participants related projects tags for things like the theme of work or functional area If the note is documenting the outputs of a meeting, we also add a date and a meeting type. Project brief template from the notes database Project template from the projects database\nHow this process has evolved over the past 6 months Earlier this year I wrote a couple of blog posts about how we are using Notion. Most of what I wrote in these posts is still applicable, but there are a few things that have changed: How we keep track of actions In my blog posts, i described how we kept tech team actions in Linear, and non tech team actions in the actions, notes and questions database in Notion. However, feedback from a team retrospective made it obvious that most people struggled with not having one place to go to track all of their actions. Someone (not me!) had the bright idea of putting all our actions in Linear, and all our notes in Notion. Saddened as I was to abandon my beautiful Notion database, I was attracted to the elegant simplicity of this rule. It was much simpler than what I had before, and is now in widespread use. This change enabled us to consolidate our Notion databses. We merged our \u0026#8220;Actions, Notes and Questions\u0026#8221; database and \u0026#8220;Meeting Notes database\u0026#8221; into a single database called \u0026#8220;Notes\u0026#8221;. Again, this has massively simplified our Notion setup, and made it easier to maintain good documentation. Renaming the bets database In How we use Notion to manage our product backlog / bets I wrote about how I like to use the word \u0026#8220;bets\u0026#8221; to descrive work we plan to do, because it captures the inherent uncertainty that any work will achieve it\u0026#8217;s desired impact. I still like the word bets. However, it was unnecesarily complicated to have a bets database linked to a projects database, and couldn\u0026#8217;t rename the \u0026#8220;projects\u0026#8221; section of Linear, so we decided to just use the word projects instead. Consistent simple communication felt more important here. October 2025 update I have noticed that this is one of my most-read blog posts, so I thought it best to provide a little update. The system described in the above blog post was in place for most of 2024. However, we encountered one big problem: Keeping Notion and Linear in sync was a pain. As work progressed from ideation to planning to delivery, it often got broken down and recombined into initiatives of different shapes and sizes. Having to change this in two separate systems every time was busywork, and things too easily got out of sync. This meant we did not have a single source of truth. In response to this and some other problems, we have improved our use of Linear and Notion in five ways: 1. Projects in Linear Should Link to Key Documentation and Have Start/End Dates Linear should be the main place people go to see: what projects and tasks are being worked on when projects will start and end a jumping-off point to find key documentation about a project Each Linear project should link to the key project documentation. The project lead is responsible for ensuring these links are up to date. This allows our team to: quickly access all the most important information about a project or feature spend less time keeping Linear and Notion in sync with overlapping information 2. Repurpose the Projects Database in Notion to Be Long-Running Areas Without Start/End Dates The Notion projects database is no longer trying to mirror Linear perfectly. Instead, it has been repurposed as a product areas database. Product areas are longer-lasting and there is a limited number of them. Each product area includes: Links to docs that don’t exist in Notion (e.g. Figma designs/Whimsical boards/Google Docs) Briefs, requirements, RFCs, decisions, meeting notes and all other documentation (powered by our Notion Notes database) 3. Understand When Content Has Been Deprecated in Notion As we grow, we are struggling to separate current documents from older versions of documents which are no longer relevant, or work that is WIP. To get around this, there is now an optional status field on all Notes to allow us to tag work as draft or archived. By default this field is empty, but people can use it to communicate the status of documentation. 4. Making Good Use of Linear Project Updates Linear has this great feature which enables people to leave updates on projects. These updates automatically get posted to a Slack channel and get saved on the Linear project page. So when you view each project, you can see links to all the key documentation, as well as a history of regular updates from each project lead. People can leave comments and emoji responses, and these get synced between Linear/Slack. Comments also include a red/amber/green status that allows people to flag when things are off track. We have worked hard to get our team into a habit of writing regular briefs on their projects, which helps everyone stay in sync. 5. Organising Projects into Initiatives Project updates are great for me as a product lead, as I need to take the time to understand the detail of what every team is doing. However, it can become a bit chaotic when we have 10+ small projects in-flight and every one of them is getting weekly updates. This is particularly problematic for executives, or those who are not as close to the work. To get around this, we have made use of Linear\u0026#8217;s initiatives functionality. Initiatives are high-level groupings of projects. We have grouped all of our work into four initiatives: two for product capabilities and two for content creation. Each initiative is aligned to outcomes we deliver for our users. Our three-week sprint review cycle is built around these initiatives, and the lead for each initiative writes an initiative update every three weeks after each sprint review. ","permalink":"https://alaniswright.com/blog/how-we-are-using-linear-and-notion-to-manage-our-product-backlog-and-project-work/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  This post describes the simple approach we have settled on to keep track of our work at Climate Policy Radar: actions on Linear and documentation on Notion.\n\u003c/p\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"how-we-use-linear\"\u003eHow we use Linear\u003c/h2\u003e\n\u003ch3 class=\"wp-block-heading\" id=\"why-we-like-linear\"\u003eWhy we like Linear\u003c/h3\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  Linear prides itself on being a simple alternative to larger more complex task management systems like Jira. Their \u003ca href=\"https://linear.app/method\" target=\"_blank\" rel=\"noreferrer noopener\"\u003emethod\u003c/a\u003e is to offer a simple tool that doesn\u0026#8217;t have all the bells and whistles of some of the bigger players. Users need to accept the constraints that come with that. But if your ways of working align with the \u0026#8220;Linear way\u0026#8221;, then you get the benefits of a super-fast tool that is easy to use. No features are missing in Linear that anyone on our team feels are must-haves, so it\u0026#8217;s an easy trade-off for us.\n\u003c/p\u003e","title":"How we are using Linear and Notion to manage our product backlog and project work"},{"content":" Good product teams are focused on rapidly delivering maximum value to their users. This post describes four factors that when kept to a minimum, enable teams to deliver more, more often and at a higher quality: cycle time, queues, work in progress and batch size. In this post, I explain what these four things are, why reducing them helps teams become high-performing and some of the techniques we can use to keep them to a minimum. Cycle time What is cycle time Cycle time is the elapsed time spent on a work item from start to finish. The stopwatch starts when work starts and ends when the work is finished, and includes any time in the middle when nobody is actively working on it. Why we should try to reduce cycle time Shorter cycle times mean that we can deliver work items (aka value) to users: faster at a lower cost at higher quality with less risk That last one about risk is one of the most important to me. Most of the time new features don\u0026#8217;t fail because they weren\u0026#8217;t usable or couldn\u0026#8217;t be built. They fail because nobody wants to use them. The quicker we fail, the faster we can change our approach, and the lower the cost of failure. That is why \u0026#8220;fail fast\u0026#8221; is such a popular term in the software world. The below images from The Agile Weekly show the relationship between cycle time, risk and batch size (which I will cover in more detail in the next section). Batch size What is batch size The size of a work item. Often measured in t-shirt sizes, or the amount of weeks it will take someone to do. Why we should try to reduce batch size Reducing batch size refers to the practice of delivering smaller increments of work rather than large, monolithic releases. Reducing batch size is probably the best way to reduce cycle time because smaller bits of work get done faster and are easier to troubleshoot if things start to go wrong. It\u0026#8217;s much easier to find a needle in a matchbox than a haystack! Big batch sizes can cause a lot of variability in queue times. Ever tried to get a train near Arsenal on match day? 60,000 people leaving the stadium all at the same time is a big batch that causes huge queues and slows down travel. Transport for London encourages people to avoid transport near stadiums on match days to reduce batch sizes. How small is too small? A good rule of thumb is that each batch of work should deliver value or learning. Beyond that, the main limit to batch size is the fixed costs associated with each batch, which we should strive to reduce. The below image from Boost illustrates how small batch sizes lead to smaller queues. Imagine each of those purple triangles representing a bunch of customers turning up at a restaurant and the amount of time they spend in queues. If loads of customers arrive at once, they\u0026#8217;ll likely spend more time in queues. Queues What are queues Queues are the list of work items that are waiting to be worked on. In product development, they can exist in ideation, discovery, design or delivery. Why we should try to reduce queues Queues can be very useful in small doses. If someone on the team finishes a piece of work earlier than expected, a small queue of well-defined and prioritised work means they can easily stay focussed on doing the most valuable thing. Work items that are in progress but stuck in queues increase cycle time and work in progress. My biggest problem with larger queues is that they cause waste. As a product manager and general plan-a-holic, I am often tempted to get ahead of the team and start defining work months ahead of time. If not done right, this risks causing waste in multiple ways (I have been guilty of all of the below): work stuck in queues for a long time is more likely to go out of date. Work that goes out of date represents wasted effort when work is stuck in a queue for ages and it needs to be picked up again, it takes time to re-learn the context. Context switching is wasted effort looking at long lists of things and wading through out-of-date documentation takes mental effort and makes it harder to focus on the actual priorities psychologically, it sucks to have a huge mountain of tasks piling up in front of you. It can really demotivate people me getting ahead of the team and defining work either means distracting team members from what they\u0026#8217;re working on now, or doing work on my own that would be best done collaboratively by a cross-functional team Work in progress What is work in progress WIP (work in progress) are work items that are being worked on at the same time. For most of us in the team that means work that is in discovery or delivery. Why we should try to reduce work in progress Most people work best when they do one thing at a time, fast and to a high-quality standard, before moving on to the next thing. Working on more than one thing at a time leads to: more multitasking. It takes time for people to switch contexts, and increases the likelihood of error higher coordination and management overhead, leading to confusion and delays increased stress for teams, who can start to feel overwhelmed by the amount of work in front of them slower cycle times and increased queues, with all the associated risks How much work in progress is not enough? I have seen small teams achieve incredible success before by focusing on one thing at a time. This meant zero queues and fast cycle time, but a hell of a lot of mob programming (a great practice in small doses, but difficult to maintain all day every day). For most teams, 2-3 things would be a more realistic minimum. The key thing is for teams to pay attention to the inefficiencies too much work in progress can cause, and try to keep them to an acceptable minimum. Techniques you can use to help Cycle time, batch size, queues and work in progress are all closely related. Reducing one often reduces most of the others. Here are a few of my favourite ways to keep them at a minimum: MVP With any piece of work, try to identify the MVP. The MVP (Minimum Viable Product) is the smallest piece of work you can do to either deliver value or validate learning. My favourite example of a MVP is Dropbox. They didn\u0026#8217;t start by building anything. They created a 4-minute video demo of how they imagine Dropbox might work. When 70,000 people signed up for their waitlist overnight, they knew they were onto something. They had validated their hypothesis that users would find Dropbox valuable at a very low cost, much quicker than they could have done by building something. 80/20 rule The 80/20 rule is another obsession of mine. The idea behind it is that for any problem you are trying to solve, you can usually deliver 80% of the value with 20% of the effort. In any new feature or functionality, look for the smallest thing you can do to deliver most of the value. Focus on doing that thing as fast as you can. Once it is done, pause and reflect on what you have learned before doing the next slice of work. More often than not, you will learn something. Visualising work Viewing all work on a Kanban board makes it easy to see where queues are building up and where there might be too much work in progress. Both Notion and Linear support viewing work in this way. Work-in-progress limits Setting limits on the amount of work that can exist in a workflow stage at any one time forces people to focus on getting things done before bringing new work into progress. Not planning for everyone to be 100% utilised What does a motorway that is 100% utilised look like? Gridlock. Everybody is blocked by everybody else. A similar principle applies to product teams. Complex work like developing software is inherently unpredictable. Unanticipated impediments, blockers, bugs and requests pop up all the time. It is also collaborative. We often need to work with others on solving problems, reviewing work and giving feedback. We are also all human: people get ill, mistakes get made and family emergencies happen. If we fail to plan for the unexpected, then we plan to fail. Assuming the team will operate at 100% results in a team consistently operating at above 100%. This leads to lots of waiting around, delays and multi-tasking (aka queues, cycle time and work in progress). More importantly, it burns people out. When agencies bill out their people, they rarely plan for anyone being utilised at more than 80% (65% is apparently the average). Teams should try to leave slack capacity so that variability in workloads can be dealt with sustainably and to ensure the things they are focussed on doing get done fast. The below image from AHA Moments shows that as people approach being 100% busy, the wait time for new tasks to be completed grows at a very fast rate. Cross-functional collaboration For complex work, groups of people with complementary skills working together on a single problem is usually the most effective way to work. Different people bring different things to the table. When you finish a piece of work, it often makes sense to ask anyone else if they need help or would like to collaborate on something that\u0026#8217;s already in progress before starting on something new. Focussed strategy Good strategy defines the many things that the team isn\u0026#8217;t going to focus on, and the few things that the team should focus most of their effort on. This enables the team to achieve maximum impact at pace with minimum effort. A clear strategy that is well understood by everyone helps keep people focussed on what matters and minimises the temptation to work on too many things at once. Continuous improvement Regular reflection by the team on how they can make their ways of working and their product better is essential. A culture of doing continuous improvement frequently and in small batches is unsurprisingly my preferred approach here. This is one of the reasons I am so in favour of teams doing regular retrospectives and being able to rapidly experiment with improvements. Definitions of done Having clear definitions of done helps us ensure work gets done to a high-quality standard. This minimises the likelihood of creating new work for the team further down the line, such as bugs, performance issues or generally slowing down future work. Testing, documentation, performance and measurement are some of the key definitions of done that teams should consider. Infrastructure to support continuous delivery Last but not least, to enable batch sizes to get smaller, we need to invest in techniques to minimise the fixed cost involved in making a change. DevOps practices like continuous integration and continuous deployment help teams make smaller changes to software at a much lower cost. ","permalink":"https://alaniswright.com/blog/cycle-time-queues-work-in-progress-and-batch-size-four-things-product-teams-need-to-reduce-if-they-want-to-deliver-more-value-faster/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  Good product teams are focused on rapidly delivering maximum value to their users. This post describes four factors that when kept to a minimum, enable teams to deliver more, more often and at a higher quality: cycle time, queues, work in progress and batch size. In this post, I explain what these four things are, why reducing them helps teams become high-performing and some of the techniques we can use to keep them to a minimum.\n\u003c/p\u003e","title":"Cycle time, queues, work in progress and batch size – four things product teams need to reduce if they want to deliver more value faster"},{"content":" Just over 1 year ago, I joined a climate tech start-up called\u0026nbsp;Climate Policy Radar\u0026nbsp;as employee #11 and their first product manager. Before that, I spent 8 years working in bigger organisations, mainly in the public sector (Government Digital Service, BBC, Land Registry) but also a bit in the private sector (Cazoo and Gameloft). In this post, I share what I have learned so far about the difference between being a product manager in a start-up vs the public sector (or big organisation vs small). Lessons cover topics like burnout, impact, networking, urgency, alignment, explaining what I do and wearing many hats. Wearing many hats The first time I was asked to design new features myself, I was a bit alarmed. Was this something I was expected to do? In larger organisations, every team would have a designer. I would describe to them the problem we need to solve, and they would take it from there. Most of the UX designers I have worked with in the past would be horrified if I handed them designs or wireframes, and the idea of me being hands-on with Figma would be the stuff of nightmares! But we don\u0026#8217;t have many of the full-time roles I have grown used to over the years, such as a service designer, interaction designer, user researcher, content designer, business analyst, performance analyst, tester or delivery manager. So these are roles that I have had to pick up and try to do myself. Delivery manager aside, these are not jobs that I have done on a full-time basis before. Before 2014 when I worked with small non-profits and digital agencies, I was also working in quite broad roles where I had to wear a lot of hats. Knowing what I know now, I didn\u0026#8217;t wear any of those hats particularly well! Over the past 8 years, I have experienced working with specialists of all disciplines who really know their craft, so I now have a much better idea of what good looks like. I also have a good network of people to reach out to for advice. Some of these ex-colleagues have been enlisted to volunteer with us a few days per year to provide advice and feedback. I have found it fun to get stuck in and try to do these things for myself. Learning by doing is the best way to learn (at least it is for me). I feel like I have achieved a lot, made a good impact and learned a tonne. Test earlier. Test more often Wearing many hats has its downsides. Chief amongst them is that it\u0026#8217;s hard to do a great job at something if you are trying to do 6 jobs! Even in the unlikely event that I was skilled enough to do each of these jobs as a specialist, there aren\u0026#8217;t enough hours in the day for me to do them all to the standard I aspire to. Especially so as we don\u0026#8217;t have a permanent product manager across every product \u0026#8211; we just have me across everything the company does. That said, even if there was time for me to do everything perfectly, it wouldn\u0026#8217;t make sense for me to do so. Why? Uncertainty. Product development in general is full of uncertainty, but especially so in start-ups. Big questions like whether we\u0026#8217;ll have funding to carry on a year from now remain unanswered. We are earlier on in the journey of discovering how best to meet user needs, what technology/design patterns to use etc. The correct response to uncertainty is to test early and test often. You can spend all the time in the World building the perfect feature. But if nobody uses it or you don\u0026#8217;t have funding to carry on, then it is a waste of time. This is also true for bigger organisations. It\u0026#8217;s just more true in start-ups where there is less to be lost from the \u0026#8220;move fast and break things\u0026#8221; mantra (as there\u0026#8217;s less to break), and more to be lost from spending months building the wrong thing (as we don\u0026#8217;t have time to waste). Communication is less complex One of the great time savers from working in a start-up is that it is easier to communicate ideas and keep people aligned. When building GOV.UK\u0026#8217;s publishing platform or BBC iPlayer\u0026#8217;s APIs, a large part of my role was spent aligning the work of my team with 20+ other teams, managing upwards to senior leaders and negotiating trade-offs with competing organisation-level goals. At Climate Policy Radar, keeping 17 people aligned takes much less of my time. This is largely because the complexity of communication increases non-linearly with organisation size. Product managers need to spend more of their time doing this in larger organisations. The strategy has to be more focused Another reason why communication and alignment are less of an overhead is that strategy needs to be more focused. Strategy is all about aligning people towards a common strategic goal so that we can maximise our leverage and achieve that goal faster and better. With 200+ people on GOV.UK, we were able to pursue multiple strategic objectives in parallel. With less than 20 people, the strategy needs to be simpler. Spreading our bets means we move too slowly, and moving fast is arguably the most important core strength of a start-up. Decisions are made faster When the opportunity arose to deliver the Global Stocktake project with the UNFCCC for Bonn, we quickly pivoted to make it our priority. In a matter of weeks, we were able to build a new product from scratch and get it in front of users who used it to do their jobs. Such a quick turnaround would have been much harder to achieve in a large organisation with team members, partners, stakeholders, business cases and dependencies between teams to manage. It is very hard to turn a big tanker fast, not without ruffling a lot of feathers! Less productive capacity The small team of ~10 I worked with on Climate Policy Radar was more productive than any cross-functional product team I have worked on before. But when a big organisation actually decides to focus on solving a problem and mobilises multiple product teams to focus on it, it will always be difficult for a small organisation to keep pace. Throughout human history, countries and companies have gained competitive advantage by organising themselves into ever larger units. I am a bit jealous of how fast my previous self has been able to scale up teams in the past! It is quite frustrating to have all these great ideas for where you want to take the product but keep saying \u0026#8220;not yet\u0026#8221; to so many of them. I am excited by the prospect of scaling the Climate Policy Radar team further. Nobody knows what I do anymore When you meet some friends of friends for the first time and you tell them what you do, it\u0026#8217;s much easier to say that you do manage GOV.UK or are digitising the Land Register. Most people know of these products. It\u0026#8217;s not so easy to do this working at Climate Policy Radar. But being able to explain what you do in a sentence or two is a pretty important thing for a product manager to be able to do well, so it\u0026#8217;s not such a bad thing to have to practice. Smaller professional network Compared to my year in Cazoo or BBC, my professional network with other digital technology professionals has grown a lot slower this year. This is to be expected because I am working with a smaller group of people. Most of the best professional opportunities I have had in life have come to me via people I have worked with in the past, so this is a bit concerning. Not too concerning though as I already have quite a big network from my previous roles. As the only product manager, I also haven\u0026#8217;t had easy access to a professional community of others doing a similar job to me from whom I can bounce ideas. Communities of practice like this are some of my favourite parts about working in larger organisations. I have tackled this by seeking out a product mentor whom I speak to once per month (thanks Matt!). I also try to grab coffee with other product people I have worked with in the past who have more start-up experience than me. Individual vs collective impact Working in a start-up, I have more agency as an individual. The time delay between my effort and the impact I have is small. In contrast, working in a bigger organisation, I have less individual agency. But the overall impact of my and my team\u0026#8217;s work is generally higher. At BBC \u0026 GOV.UK, usage was measured in millions rather than thousands. It is hard work There is so much work to do, and not many people to do it. In the first 8 months, I pushed myself very hard, working a lot of evenings and weekends. Nobody was forcing me to do this. Indeed, Climate Policy Radar has excellent policies around time off and mental well-being, and we are actively building a culture where people don\u0026#8217;t feel that they need to be online 24/7. I have always been someone who is prepared to put in extra hours at work. But I think the fact that product managers in start-ups have so much more agency to impact things as individual contributors themselves, I find it even more tempting to keep on pushing myself harder. About 8 months in I started to burn out. In the past, I have burnt out because of having to work in a toxic organisation or from pouring my heart and soul into a body of work which fails spectacularly (eg. losing an election campaign or losing funding for the team). But this time was different. Everything was going super well. My burnout came around the time we launched our gst1.org tool at the Bonn Climate summit, which is probably the most amazing career experience of my life. In the past 6 months, I have gotten much better at putting boundaries in place to give myself time to switch off. This includes disconnecting all work accounts from my devices on weekends, switching off at a reliable time most evenings and scheduling regular time for breaks. I will always be happy to put in the extra hours where needed. But for business as usual, I have tried to get better at using the time I and my team have more effectively. This is good practice no matter what size organisation you are working in. But it\u0026#8217;s probably a bit easier to do in larger organisations where there are more processes in place and workload is generally more predictable and manageable. Where next for me? Towards the end of my time in the public sector, I was growing quite frustrated with the slow pace, bureaucracy and lack of agency. I needed to change things up and was very keen to give start-up life a try. One year in at Climate Policy Radar and I am having a great time, and am planning on being here for quite a while. But trying something different has given me a bit of perspective, and I do have more appreciation for some of the benefits of working in a large organisation than I did a year or two ago. ","permalink":"https://alaniswright.com/blog/being-a-product-manager-in-a-start-up-vs-the-public-sector-big-organisation-vs-small/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  Just over 1 year ago, I joined a climate tech start-up called\u0026nbsp;\u003ca href=\"https://climatepolicyradar.org/\" target=\"_blank\" rel=\"noreferrer noopener\"\u003eClimate Policy Radar\u003c/a\u003e\u0026nbsp;as employee #11 and their first product manager. Before that, I spent 8 years working in bigger organisations, mainly in the public sector (Government Digital Service, BBC, Land Registry) but also a bit in the private sector (Cazoo and Gameloft).\n\u003c/p\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  In this post, I share what I have learned so far about the difference between being a product manager in a start-up vs the public sector (or big organisation vs small). Lessons cover topics like burnout, impact, networking, urgency, alignment, explaining what I do and wearing many hats.\n\u003c/p\u003e","title":"Being a product manager in a start-up vs the public sector (or big organisation vs small): what I have learned from the past year"},{"content":" Why we do user research and what we have learned so far When we started building Climate Policy Radar, we had lots of assumptions about who our users were and what solutions would help them. User research has helped us ensure our research tool meets the needs of the people we’re building it for \u0026#8211; mainly “knowledge workers”. These are people processing large quantities of messy textual data: policy analysts, academics and risk modellers. In this blog post, we’ll explain why we carry out user research, how we’ve done it so far, what we’re learning, and some of the improvements we’re making in response. Why we do user research User research is a systematic process of understanding the needs, preferences, behaviours, and motivations of the people who use our tools. It has helped us refine our approach to building our tools and helped us tweak, validate, and sometimes completely invalidate the assumptions that we started with nearly three years ago. We’re also using AI technologies that are still quite new, and we operate in a domain where rapid change is needed and expected. The best way to ensure we focus on the right areas is to talk to our users regularly. Things we want to learn during user research include the type of knowledge work the user does (e.g. are they a policymaker or academic) and what questions they are trying to answer\u0026nbsp; their existing research process and which parts they most struggle with\u0026nbsp; how and why people use our tools and what might make them more useful Insights from user research help us make sure that we are evidence-based in our decision making and in setting our priorities for future improvements.\u0026nbsp;\u0026nbsp; How we carry out user feedback conversations There are many different approaches to user research, but the main method that we’ve used so far is user feedback conversations. These are 15-45-minute conversations with someone who has used our product or might use it in the future. We invite every user who contacts us to join a user feedback session. This includes people who submit a law or policy document or request to download our data. Our feedback conversations typically involve us asking the user questions about how they found us, what their role is, and what their work in climate policy involves to share their screen and show us how they work and how they use our tools, or try out new features that we are developing what problems they’re struggling with and how our tools might evolve to help them in the future We have had lots of valuable chats with users at events, like UN climate conferences, and in workshops. In addition, more than 70 people have signed up for 20-minute conversations. Most have given us much more than 20 minutes of their time and agreed to follow-up conversations, and none have been paid.\u0026nbsp; What we have learnt so far Conversations with users have helped us validate that people find our tools valuable,\u0026nbsp; identify problems with our design that are making them difficult to use and find ways to make our tools better.\u0026nbsp; We have spoken to a wide variety of users across the world who use our tools in many different ways. This includes civil servant policy analysts, NGO researchers, PhD students, risk modellers, scientific advisors and many more. A common finding across these conversations has been that our users are knowledge workers who answer research questions as part of their jobs. The knowledge workers that we are concerned with specifically answer their research questions by applying a research process to large libraries of long, dense, unstructured documents. They are searching for nuggets of information to use in artifacts like policy options papers, policy reports or data models. These knowledge workers have given us a lot of positive feedback: “CPR are like the Google of climate policy” and “Instead of having to look in 30 different places I can find it all in a one stop shop” are two of my favourites. We have also learnt a lot about things we need to improve. “Translation is the problem you need to solve.” We spoke to a senior civil servant involved in a recent UNFCCC COP summit. In the build up to the summit, hundreds of documents were released in numerous different languages, which people needed to read and synthesise quickly. A particular pain point for them was not being able to easily read and understand documents written in languages other than English. As a result of this and other feedback, we brought\u0026nbsp;UNFCCC documents into our tools\u0026nbsp;and enabled\u0026nbsp;translation of search results\u0026nbsp;so that our users can now read documents written in any language. “I didn’t realise that was how it worked” We spoke to many academics who were using our search tool to speed up the process of finding information in long and complex documents. Interestingly, some were opting to use our exact match search instead of our semantic search tool, which identifies related phrases such as “zero-emission cars” and “EVs” if you search for “electric vehicles”. They revealed that this was because they were surprised when they saw matches highlighted that didn’t match their search query and assumed that the search was broken. We adjusted the design on our search page, using new language to make it easier for people to understand how our search function works. In subsequent user feedback sessions we tested whether people understood this new content before releasing it to users. “Extracting structured data from policy documents ourselves would be ideal, but we never have time” We spoke to an economist at an international organisation. They are using spreadsheet based models to help governments estimate the impact of climate policy. A pain point for them is access to structured data. They don’t have time to extract data from long policy documents themselves, and rely on data from third parties who curate this information. The ability to easily find all passages containing climate targets in a document and extract it into a table would massively improve this economist’s models. This feature is currently in development, and this user has agreed to provide early feedback on prototypes.\u0026nbsp;\u0026nbsp; Help us improve even more These are just some of the many things that we have learnt from user research so far, but we have a lot more to learn. We have many thousands of people using our tools every week.\u0026nbsp; We want to speak to as many users as we can so we can understand what areas of improvement to focus on and test out designs for new features. Would you like to have a user feedback conversation with us? Or do you know anyone who might? Book a slot to speak to our team. This blog post was originally published on Climate Policy Radar ","permalink":"https://alaniswright.com/blog/the-value-of-user-research/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  \u003cem\u003e\u003cstrong\u003eWhy we do user research and what we have learned so far\u003c/strong\u003e\u003c/em\u003e\n\u003c/p\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  When we started building Climate Policy Radar, we had lots of assumptions about who our users were and what solutions would help them. User research has helped us ensure our research tool meets the needs of the people we’re building it for \u0026#8211; mainly “knowledge workers”. These are people processing large quantities of messy textual data: policy analysts, academics and risk modellers. In this blog post, we’ll explain why we carry out user research, how we’ve done it so far, what we’re learning, and some of the improvements we’re making in response.\n\u003c/p\u003e","title":"The value of user research"},{"content":" If you have ever worked with a software or agile team before, you have probably done a daily stand-up. In this blog post, I share my thoughts on why daily stand-ups are useful and some tips on how to run them well. About stand-ups What is a stand-up? Stand-ups are regular meetings for the team to synchronise. They are usually held daily last 15 minutes or less (the idea behind standing up is that the lack of a chair encourages people to be brief.) combined with less regular meetings such as planning, retrospectives and show \u0026 tells You might have called this the \u0026#8216;daily scrum\u0026#8217; if you\u0026#8217;re working with the scrum methodology. Why are stand-ups useful? Coordination. Team efforts usually require different people to work on different parts of a problem. Stand-up is a forum for them to coordinate their efforts. Focussing on the right things. Misunderstandings are abundant when groups of humans communicate. Communicating progress and priorities every day reduces the risk that people will waste lots of time by prioritising the wrong thing or solving the problem in a sub-optimal way. Unblocking progress. Stand-ups draw attention to work that is blocked or that someone is struggling with. This enables the team to swarm on the problem, maximise flow and get work back on track. Team building. We form strong social bonds with people we see and speak to every day. Stand-ups are an important opportunity for face time with the team (especially for remote or hybrid teams). Types of stand-up Round robin This is the most well-known stand-up format. Each team member takes it in turns to talk about things like: What they did yesterday What they\u0026#8217;ll do today Anything that\u0026#8217;s blocking them or they need help with Teams often vary the questions that they answer in stand-up, but the key point with the round-robin is that each person takes turns to speak. What order do people go in? A pre-defined order helps everything to go a bit quicker. Encouraging people to self-organise by nominating each other or volunteering themselves is usually a bit slower, but keeps people more engaged. On one team, we had a cuddly toy that we threw to each other during stand-up when it was someone\u0026#8217;s turn to speak. That kept people on their toes! The big problem with the round-robin approach is that it creates too much of a focus on what individuals are doing, rather than what is moving the product forward. People often feel a need to say lots of things to show how busy they are, but that makes the meeting less valuable to everyone else on the team. Another problem is that all too often people zone out. While others are speaking, people are thinking about what they will say, and thus not properly listening to others. Walk the board Instead of going person by person, another approach is to go task by task. For me, this usually means starting on the right-hand side of the task board and working our way left, asking for updates on each item. The structure for a walk-the-wall stand-up might be: What did we achieve yesterday (done) What are we blocked on (blocked) What needs reviewing (review) What are we working on now (in progress) Is there anything on the priority list people plan to start on today? Is there anything anyone needs help with? Any other business This is usually my preferred approach, as it keeps teams focussed on the actions rather than the individuals encourages team members to maintain an up-to-date task-tracking system Two problems with this approach it can lead to cluttered task management systems as team members know they can only speak about tasks that get spoken about sometimes, the task management system tracks work at a finer level of detail than is necessary for discussion at a stand-up. This can lead to stand-up meetings taking longer and going into more detail than necessary Asynchronous stand-ups In an asynchronous stand-up, team members write their updates into some sort of system (usually Slack or Teams). This is an excellent substitute for a face-to-face meeting. Occasionally, stand-up has to be cancelled because some people have a meeting clash. When that happens, teams I have worked on often decide to do an asynchronous stand-up instead. The best practice for an asynchronous update is for each topic to be its own separate post. That enables a targeted conversation to take place in the comments. I have yet to work in a team that wants to make a regular habit of asynchronous stand-ups. This is partly because the social element of stand-ups gets a bit lost when people do written updates alone. One of the teams I am working with right now is fully remote. For them, the social elements to stand-up are an important one. They like to have a bit of a chat and share a few jokes before diving into the work. For them, this is a substitute for those waterfall conversations that happen naturally in an office environment. Other things to consider How to handle questions, discussions or issues Stand-ups are a forum for identifying problems \u0026#8211; not for solving them. My rule of thumb is that if someone asks a question in the daily stand-up, and it takes more than one round of interaction between the people asking and answering the question to resolve, then that discussion should be parked and picked up again after stand-up. This keeps stand-up brief and frees up anyone who doesn\u0026#8217;t need to be in that discussion to get back to their priorities. Holding stand-ups at non-disruptive times I am a massive fan of encouraging teams and individuals to organise their diaries in ways that maximise uninterrupted focus time. Some of the best ways to do this is to hold meetings: at the beginning or end of each day adjacent to other meetings at times of day that make sense to most people on the team As stand-up is usually a daily meeting, it is critical that this meeting minimises disruption. My current team does stand-up at 9 a.m. every morning. I am not a fan, as it means doing my morning swim in a more crowded swimming pool. But the team love it, as it allows them to get all their coordinating work out of the way in the morning, and allows them to focus throughout the late morning and afternoon. Every team is different, and each is best off finding different patterns that work for them. Not holding stand-ups every day / for 15 minutes / whilst standing up I always encourage teams to start by doing a stand-up every day. However, some teams have decided against that over time. One team I am working with prefers bi-weekly syncs for 30 minutes instead. As long as the goals of stand-up are met somehow, then this is fine. As far as I am concerned, there is no rule saying that stand-ups have to be daily, for 15 minutes, and done whilst standing up. Teams should be encouraged to reflect upon and regularly improve their ways of working. Where to hold a stand-up Before the advent of remote working, my answer to this question would always be that the team should meet in the team space. Nowadays, some or all team members are usually remote. It is very hard to make a team space (or indeed, any space) work effectively for hybrid meetings. So nowadays, most stand-ups happen online with everybody dialling in from a quiet space on their own devices. Who attends Everyone on the team should attend stand-up. People involved in the work but not full-time members of the team might also benefit from attending all or some of the time (eg. to stay up to date with a project they are involved in.) I\u0026#8217;m wary about people not involved in the work or only loosely involved from coming to the daily stand-up, as it can mean the team has to take longer to explain things to get them up to speed or disrupt the team\u0026#8217;s stand-up processes. More people also usually means longer meetings. I prefer to keep stakeholders only loosely involved in the work up to date on a weekly or fortnightly cadence by a combination of week notes and the regular show \u0026 tell. Making the most of habits (and breaking them from time to time) Good habits help us do the right thing, regularly without effort. Doing stand-up at a consistent time/place and following best practices is a good habit to get into. But sometimes, doing the same thing every day can encourage people to get distracted and zone out. To keep things interesting and keep people fresh and engaged, I look to do stand-ups in different ways from time to time. For example, we might do a round-robin stand-up most days. But once a week or fortnight we might try to walk the wall or do an asynchronous stand-up. Hearing about a blocker for the first time at stand-up If someone encounters a problem that they need help solving, they shouldn\u0026#8217;t wait until stand-up before talking to the team about it. A lot can be achieved by a high-performing team in 24 hours! Don’t be afraid to say “no update” One of the big anti-patterns with all forms of stand-up is that people feel they have to say lots of things to appear busy. This is a waste of everyone\u0026#8217;s time. The less unimportant things we say, the easier it is to hear the important things loud and clear. Leaders can encourage good behaviour by saying \u0026#8220;no update\u0026#8221; when they have no update to give and encouraging team members to do the same. Nobody needs to hear a list of all the meetings someone attended or about all the line management work they had to do, so just say \u0026#8220;no update\u0026#8221; or \u0026#8220;work in progress\u0026#8221; instead. Inappropriately long updates If team members talk too much too often, I might try to start a discussion at retrospective about the right level of detail to go into at stand-up. I might also get in touch with individuals to provide some 121 feedback when appropriate. Lateness If a team member is making a regular habit of being late, it is probably worth chatting to them directly to find out why. Stand-up should be brief. Starting a 10-15 minute meeting 5 minutes is not a good habit to get into. Encourage self-organisation Whoever facilitates stand-up should work hard to make themselves replaceable. I recommend either rotating the facilitator or encouraging team members to self-organise to make stand-up happen. The facilitator or team leader should also watch out for participants reporting to them rather than each other. Stand-up should be by the team and for the team \u0026#8211; not a method of reporting back to the leader. I often deliberately stay very quiet on stand-ups to encourage the team to self-organise without me. I also minimise eye contact when people are talking to me to encourage them to talk to each other rather than report to me. Great things to overhear in stand-up (especially if it’s not the facilitator who says it) \u0026#8220;Let\u0026#8217;s get started.\u0026#8221;\n\u0026#8220;Shall we take this discussion offline?\u0026#8221;\n\u0026#8220;I\u0026#8217;ve solved a similar problem before. Let\u0026#8217;s chat after stand-up.\u0026#8221;\n\u0026#8220;I am blocked on this. Can anyone help?\u0026#8221;\n\u0026#8220;Here is a new risk I have spotted with our current approach.\u0026#8221; ","permalink":"https://alaniswright.com/blog/how-to-run-a-daily-stand-up/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  If you have ever worked with a software or agile team before, you have probably done a daily stand-up. In this blog post, I share my thoughts on why daily stand-ups are useful and some tips on how to run them well.\n\u003c/p\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"about-stand-ups\"\u003eAbout stand-ups\u003c/h2\u003e\n\u003ch3 class=\"wp-block-heading\" id=\"what-is-a-stand-up\"\u003eWhat is a stand-up?\u003c/h3\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  Stand-ups are regular meetings for the team to synchronise. They are usually\n\u003c/p\u003e\n\u003cul class=\"wp-block-list\"\u003e\n  \u003cli\u003e\n    held daily\n  \u003c/li\u003e\n  \u003cli\u003e\n    last 15 minutes or less (the idea behind standing up is that the lack of a chair encourages people to be brief.)\n  \u003c/li\u003e\n  \u003cli\u003e\n    combined with less regular meetings such as planning, retrospectives and show \u0026 tells\n  \u003c/li\u003e\n\u003c/ul\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  You might have called this the \u0026#8216;daily scrum\u0026#8217; if you\u0026#8217;re working with the scrum methodology.\n\u003c/p\u003e","title":"How to run a daily stand-up"},{"content":" When a new team is formed or an existing team goes through change, it is important to take some time for team members to learn more about who each other are and how best to work together. In this post, I summarise my two favourite workshops to help teams get off to a good start: team manual and team charter. Team Manual I first learnt about the\u0026nbsp;team manual exercise\u0026nbsp;from\u0026nbsp;Emily Webber, who I worked with at the Land Registry. It is the best workshop format I have found for kicking off new teams. Each person takes the time before the meeting to answer 9 questions. They write their answers in Miro, Whimsical, a slide deck, or perhaps even on some paper if everyone is in the office. They then take time to explain what they\u0026#8217;ve written to the team. The questions are designed to help others learn about who each other are and how they like to work, so there are usually some questions or better yet a bit of good-natured banter at the end of each presentation. At the end, everybody can refer back to each other\u0026#8217;s manuals if they need a reminder of each other\u0026#8217;s preferences. Check out Emily\u0026#8217;s website for instructions and a template. Taking inspiration from the\u0026nbsp;skills market\u0026nbsp;exercise, I have recently added 3 new questions to the team manual template that I use. This enables everyone to build an understanding of each other\u0026#8217;s roles, professional strengths and learning priorities without having to run a separate workshop. The questions I added are: Current skills (that allow me to do my job) Hidden skills (you might not know I have) Desired skills (I want to develop or learn) This exercise usually takes about 90 minutes to do for a team of 8 or 9. Below is a screenshot of the template I use to run the team manual in Whimsical Team Charter The team charter documents the team\u0026#8217;s values and working practices. It takes everything everyone has learnt about each other from the team manual exercise and turns it into a set of ways of working that should work well for the team. I used to run this exercise by posing the question “This is an awesome team to work on because…” and giving everyone 5 minutes to write their ideas. We then talk through what we\u0026#8217;ve added, group and theme the ideas, and vote on our favourite ones. Someone volunteers to write this into a team charter poster after the meeting, and everyone gets a chance to review it before it is finalised. Once finished, it should be printed and put up on the wall in the team space, and/or stored somewhere prominently in one of the team\u0026#8217;s electronic tools. Nowadays, I prefer to use the anti-team charter format. Again, this is a format that I first used at the Land Registry, though I can\u0026#8217;t find it documented anywhere online. Instead of asking people to answer the question “This is an awesome team to work on because…”, they instead answer the question \u0026#8220;This is the worst team to work on because\u0026#8230;\u0026#8221;. In the end, the person doing the writing writes up the opposite of what the worst team in the World does. And this becomes how the team will try to work together. I find that the workshop is a lot more fun this way \u0026#8211; people can get creative about some of the bad team behaviours they write up, and they get to exchange some horror stories about toxic workplaces. This exercise takes about 45 minutes to do. Below is an example of a team charter from the GOV.UK Content History Team. Positive outcomes I have been running these workshops in this format for about 5 years now. Everywhere I have done them I have had good feedback from participants, and have often found myself drafted in to facilitate similar workshops for other teams or organisations. Examples of positive signals I see after running these workshops include team members: being mindful about each other\u0026#8217;s focus time and productive times of day when scheduling work and meetings using their regular retrospectives to hold each other account on sticking to their team charter striking up friendships as they find out new things that they have in common Need help facilitating these workshops for your team? Get in touch! ","permalink":"https://alaniswright.com/blog/team-manual-and-team-charter-my-two-favourite-workshops-to-run-with-new-teams-or-teams-with-new-members/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  When a new team is formed or an existing team goes through change, it is important to take some time for team members to learn more about who each other are and how best to work together. In this post, I summarise my two favourite workshops to help teams get off to a good start: team manual and team charter.\n\u003c/p\u003e\n\u003ch3 class=\"wp-block-heading\" id=\"team-manual\"\u003eTeam Manual\u003c/h3\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  I first learnt about the\u0026nbsp;\u003ca target=\"_blank\" href=\"https://emilywebber.co.uk/the-team-manual-a-exercise-to-help-build-empathy-in-teams/\" rel=\"noreferrer noopener\"\u003eteam manual exercise\u003c/a\u003e\u0026nbsp;from\u0026nbsp;\u003ca target=\"_blank\" href=\"https://emilywebber.co.uk/\" rel=\"noreferrer noopener\"\u003eEmily Webber\u003c/a\u003e, who I worked with at the Land Registry.\n\u003c/p\u003e","title":"Team manual and team charter – my two favourite workshops to run with new teams or teams with new members"},{"content":" This blog post explains why and how we (Climate Policy Radar) decided to split from one big product team into two smaller teams. The problem with working as one big team As the team grew in size, we found it increasingly difficult to do everything together as a whole team.\u0026nbsp; Meetings took a long time to get through. Most people found it difficult and unnecessary to stay on top of everything being done across the organisation.\u0026nbsp; “Not having enough focus time to get things done” had started to come up in retrospectives.\u0026nbsp;\u0026nbsp; We had 14 people and more hires on the way.\u0026nbsp; As you can see from the below image, that meant many lines of communication to stay on top of.\u0026nbsp;\u0026nbsp; Lines of communication and team size. Source: leadingagile.com\n14 is a lot of people for one team (and we were scheduled to be 17 within a couple of months).\u0026nbsp; But it’s not a lot for a multi-team organisation.\u0026nbsp; Having multiple teams usually means there needs to be a coordinating team to join the dots, but with only 2 teams to coordinate there’s a real risk that a coordinating team becomes overkill. Four goals of our new two-team approach Have small multidisciplinary teams with all the skills and capabilities they need to deliver value with minimum dependencies Ensure teams stay aligned with minimum overhead Reducing meeting and information overload to give people more focus time Maintain strong social bonds as an organisation Below I describe the approach we took for each. 1: Have small multidisciplinary teams with minimum dependencies What size is right? Teams need to be big enough that work doesn’t grind to a halt when one or two people are away, and small enough that all the lines of communication don’t slow everyone down.\u0026nbsp; In this thoughtful article about recommended team sizes, 9 is generally accepted as the maximum team size with lots of evidence indicating that this is too large in most cases. So I encouraged us to aim for team sizes of between 4 and 8.\u0026nbsp;\u0026nbsp; Where to draw the dividing line? My most important consideration was ensuring that each team had all the skills and capabilities they needed to deliver value autonomously. This is so that dependencies between teams would be minimised.\u0026nbsp; I also didn’t want to be reforming teams every couple of months. High-performing teams develop with time, and constant change is disruptive (I learnt this lesson the hard way during our experiment with quarterly planning on GOV.UK).\u0026nbsp; Through our work on launching the Global Stocktake Explorer, we had organically started to work as separate subgroups. Data scientists and policy analysts were focused on collecting, preparing, structuring and analysing UNFCCC data. Engineers were focused on building the product, and our product’s capability to support bespoke project work (in this case, it meant ingesting and parsing the UNFCCC data). Our data engineer and frontend developer found themselves contributing a little bit to both teams. Looking ahead at our roadmap for the next 6 months, this division continued to make sense. There was a clear need for data science and policy to work together to deliver bespoke projects for partners and experiment with ways to measure, structure and improve our data. The engineers needed to focus on building the product capability to bring in more structured data at scale. There would still be a need for collaboration between teams. But this approach meant fewer dependencies between teams than any other option we could think of. So we decided to split into two teams. The teams got to pick their own names, and in an attempt to describe what the teams were doing, we ended up with one team called \u0026#8220;R\u0026D\u0026#8221; and the other team called \u0026#8220;Product\u0026#8221;. Naming teams\nI regret that the teams ended up being named R\u0026D and Product (even though initially it was my idea). There are two problems with this. Firstly, naming the teams in this way creates the impression that one team hands off discovery findings to the other to build. This is not the type of culture we want to promote \u0026#8211; both teams should be doing a mix of discovery and delivery activities.\u0026nbsp; Secondly, it confuses team names with other words that we use day-to-day in our communication with each other.\u0026nbsp;\u0026nbsp; Dividing along functional lines\nOne thing that makes me nervous about this split is that it mostly involves engineers on one team and non-engineers on the other. There is a real risk that this could create dysfunctional silos. Once the product reaches a level of technical capability where data science insights can be more rapidly integrated into product, I would like us to explore more cross-functional teams which combine software engineering, data engineering, data science and policy people. A product manager on each team\nWe are fortunate to have a new associate product manager join us a few weeks ago. We will each focus on separate teams, but I’ll also mentor her and lead product strategy at the organisation level. How we handle cross-team work\nThe assumption is that most people will spend 95% of their time working with other people on their team. The exceptions to this are our: Data Engineer. He will be working across both teams.\u0026nbsp; This is a bit frustrating for him as he needs to be in double the meetings. But he’s making the most of it and is helping to keep both teams aligned. Lead Engineer and Lead Data Scientist.\u0026nbsp; They need to work together a fair amount both to keep their respective teams aligned and to pair on some of the upcoming functionality that requires both of their skill sets. There will always be a need for people from different teams to work together on an ad hoc basis. When this happens we will encourage people to self-organise.\u0026nbsp; We might also set up temporary teams or temporarily have people join other team meetings.\u0026nbsp; Though if this type of cross-team work happens a lot in consistent ways, that will indicate that we might need to rethink our team topology. 2: Ensure teams stay aligned with minimum overhead Shared strategy. Both teams are working towards common strategic priorities.\u0026nbsp; For example, our next strategic priority is to bring passage-level structure to documents.\u0026nbsp; This requires the R\u0026D team to improve the quantity and quality of concepts we can detect at passage level.\u0026nbsp; And it requires the Product team to enable the product to display this data to our users.\u0026nbsp;\u0026nbsp; Shared show \u0026 tell. Our weekly organisation meeting includes a show \u0026 tell with members from both teams presenting progress, and leadership providing strategy updates.\u0026nbsp; This ensures strategic direction, learnings and progress are shared.\u0026nbsp; There is a real focus on making sure we have lots to share at show \u0026 tell and that it is recorded for anyone absent to watch in their own time.\u0026nbsp; Shared weeknote.\u0026nbsp; Our weekly note includes work done last week / planned for next week from each team.\u0026nbsp; This keeps everyone aligned on what is happening in the week ahead.\u0026nbsp; We take great care to write a thorough weeknote which captures all the key progress throughout the week, and flags key updates in Slack that might have been missed during the week. Shared multi-team plan.\u0026nbsp; This allowed us to see all work from both teams in one place, and see where there are dependencies that might need to be managed.\u0026nbsp; Fortnightly review of the multi-team plan. Every fortnight, one or two representatives from each team look ahead at the plans for the month ahead, with a focus on managing risks and dependencies. Use of public slack channels/task tracking/documentation storage.\u0026nbsp; All information is open by default. Various regular 121s between team members on different teams. Eg. CTO, Data Science Lead and Engineering Lead meet weekly. And Product Managers from each team meet most days. 3: Reducing meeting and information overload to give people more focus time One all-team meeting per week.\u0026nbsp; We stripped back our all-team meetings to just one at the end of the week.\u0026nbsp; This is the all-hands that includes strategic updates and show \u0026 tell. Team meetings are more focused.\u0026nbsp; Only having 5 or 6 people in a meeting means that team time together is much more productive than it was before. Each team decides a cadence for planning, standups and retrospectives that work best for them.\u0026nbsp; Both teams are adopting different approaches: one team likes to get all their meetings out the way at 9 am and focus for the rest of the day.\u0026nbsp; One team have clumped all their meetings into two afternoons per week.\u0026nbsp; Both teams are using their retrospectives to continuously improve their ways of working.\u0026nbsp;\u0026nbsp; Everyone is being encouraged to think about how they can maximise their productive time as a team and as individuals.\u0026nbsp; Read my previous post on managers and makers time for more on this topic. 4: Maintain a strong organisational culture Have a regular program of offsites and away days that all team members attend. We have some fully remote team members, but we try to make sure we come together as a full organisation every couple of months.\u0026nbsp; When we do, we always plan socials. All team retrospectives. Every couple of months, we take half a day to have an all-team retrospective.\u0026nbsp; It’s not easy to do a retrospective with 14+ people in an hour. We found that doing retrospectives less often but more thoroughly gives us the chance to dig into the detail about what needs to be improved and identify actionable improvements we want to make as a team. Two days per week in the office.\u0026nbsp; Most of our team live within commutable distance of London. We generally all work in the office for 2 days per week and all try to do lunch together when we do. Everything I mentioned under Goal 2 to ensure teams stay aligned also helps maintain a strong organisational culture. Thanks for reading! All views are my own and not those of my employer. ","permalink":"https://alaniswright.com/blog/splitting-one-product-team-into-two/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  This blog post explains why and how we (\u003ca href=\"https://climatepolicyradar.org/\"\u003eClimate Policy Radar\u003c/a\u003e) decided to split from one big product team into two smaller teams.\n\u003c/p\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"the-problem-with-working-as-one-big-team\"\u003eThe problem with working as one big team\u003c/h2\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  As the team grew in size, we found it increasingly difficult to do everything together as a whole team.\u0026nbsp; Meetings took a long time to get through. Most people found it difficult and unnecessary to stay on top of everything being done across the organisation.\u0026nbsp; “Not having enough focus time to get things done” had started to come up in retrospectives.\u0026nbsp;\u0026nbsp;\n\u003c/p\u003e","title":"Splitting one product team into two"},{"content":" Quantitative product metrics help us to understand whether our product is getting better, how people are using our tools and where they might be encountering problems. In this blog post, I explain how we (Climate Policy Radar) defined our user lifecycle funnel and tracked it in Google Analytics. What is a user lifecycle funnel? Our user journey mapped onto our user lifecycle funnel\nI first learnt about this concept in Laura Klein’s book ‘Build Better Products’ (from which the image below is borrowed). If you work in product management or design I strongly recommend you give it a read. A user lifecycle funnel helps us understand: the stages a user goes through when going from a first-time visitor to becoming a happy recurring user\u0026nbsp; what proportion of users are dropping out at each stage As a product manager, this helps me prioritise where we need to focus our efforts to make our tool more valuable to our users. It’s also one of the best tools I’ve found for onboarding new team members and explaining how the product works. User lifeycle funnel from Laura Klein. Source: ZipBoard blog\nBelow are our 5 stages and how we track them in analytics. Note that I decided against tracking revenue, as our product is not a commercial one. Step 1: Awareness What it is: how we get people to hear about our product. How users become aware: Search engines, referring sites, social media and PR/marketing. The metric that indicates if a user is aware: unique visits. How we track this in analytics: unique visitors is a default metric in Google Analytics. Step 2: Education What it is: how we help people learn enough about our product to know they want to use it.\u0026nbsp;\u0026nbsp; How users become educated: The intro text on our homepage, FAQs, explainer videos and good UI/UX are the main ways. The metric that indicates a user knows enough about our product to want to use it: usage of search. How we track this in analytics: visits to the search results page/site search usage event. The only thing we had to do here was enable advanced tracking of search so that we can see how different search terms/parameters are performing. Step 3: Engagement What it is: how users will achieve something valuable using our tool. How users become engaged: this one is harder for a content site like ours. Some users might find all the information they need by browsing document titles on the search results page, reading summaries of each document or downloading the document as a PDF. However, right now our key differentiator from other similar products is that we enable users to search the full text of documents for exact matches, related phrases and even translations of non-English documents. We return them a list of passages that match their search highlighted in the original document. So my engagement metric focuses on these differentiators. The metric that indicates a user is engaged: interaction with passages that match their search, the document viewer or the download link for the original document. How we track this in analytics: this one required us to add some custom tracking to our tool so that we could measure how many users were interacting with our physical document page. This includes interaction with the: \u0026#8220;matches in document\u0026#8221; element (left-hand side) document viewer (right-hand side) original document link We also set up some custom variables on document pages so that we could understand how different types of documents perform. These include things like category (eg. policy), type (eg. strategy), country, data, language, translation and format. Step 4: Recurrence: What it is: how users will become regular users. Users will become long-term recurring users if they find enough value in our product to come back and use it again. As we build up data on which users are coming back and how often, we will try to discover what happens early on in their use of our product to turn them into repeat users. Facebook famously found that users who connected with seven friends in their first ten days were more likely to become active retained users. Success at this stage when: a user returns to the site. How we track this in analytics: my favourite way of doing this is to look at cohort retention. This shows what percentage of new users from a given week are still active in future weeks. We also use the default returning users metric and keep track of how many users return to the site and perform specific actions on their original and repeat visits, such as performing a search or viewing document passage matches. This is tracked via event tags set up in Google Tag Manager Cohort retention example. Source: Lenny Rachitsky\nStep 5: Conversation: What it is: how we will get permission to communicate with users. I renamed this from ‘conversion’. In e-commerce, a conversion is a purchase. For us, the main aim of this stage of the funnel is to see how many users value our tools enough to start a conversation with us, and the knowledge we’ll get about our users by being able to do\u0026nbsp;user research\u0026nbsp;with them. This gives us rich qualitative insight into how users are using our tool, and what impact the tool is having. These conversations give us an evidence base for conversations with partners and donors about our impact and help us to plan future improvements. How we attract users to start a conversation: contacting support, filling in a feedback widget or micro survey on our site, requesting to download a CSV of our data, signing up for our newsletter, signing up for an alert for when new features become available and submitting missing data are all ways in which we get the conversation started with users. Longer term, my account functionality like search alerts of custom collections will help us start conversations with more users.\u0026nbsp; Success at this stage when: total number of users contacting us for any of the above reasons. How we track this: this isn’t something we track in analytics tools. It has to be measured manually by collating the results from all our CRM and all our different Google Forms.\u0026nbsp;\u0026nbsp; Next steps Tracking this data has helped me spot where in our product lifecycle users are dropping out. These are the areas where we need to focus our attention to so that we can maximise the number of users who get value from our tools. In a future blog post, I will explain a bit more about what we learnt, how we conducted further research to better understand the problem space, and some of the improvements that we prioritised in response. Last but not least, I want to say a big thank to Anne Cremin. She has kindly been volunteering her time with Climate Policy Radar to help us out with our Google Analytics and Google Tag Manager set up. Thanks Anne! ","permalink":"https://alaniswright.com/blog/tracking-our-products-user-lifecycle-funnel-in-google-analytics/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  Quantitative product metrics help us to understand whether our product is getting better, how people are using our tools and where they might be encountering problems. In this blog post, I explain how we (\u003ca href=\"https://climatepolicyradar.org/\"\u003eClimate Policy Radar\u003c/a\u003e) defined our user lifecycle funnel and tracked it in Google Analytics.\n\u003c/p\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"what-is-a-user-lifecycle-funnel\"\u003eWhat is a user lifecycle funnel?\u003c/h2\u003e\n\u003cfigure class=\"wp-block-image size-large\"\u003e\n\u003cp\u003e\u003ca href=\"https://alaniswright.com/wp-content/uploads/2023/07/image-3.png\"\u003e\u003cimg loading=\"lazy\" decoding=\"async\" width=\"1030\" height=\"681\" src=\"https://alaniswright.com/wp-content/uploads/2023/07/image-3-1030x681.png\" alt=\"\" class=\"wp-image-663\" srcset=\"https://alaniswright.com/wp-content/uploads/2023/07/image-3-1030x681.png 1030w, https://alaniswright.com/wp-content/uploads/2023/07/image-3-300x198.png 300w, https://alaniswright.com/wp-content/uploads/2023/07/image-3-768x508.png 768w, https://alaniswright.com/wp-content/uploads/2023/07/image-3-1536x1016.png 1536w, https://alaniswright.com/wp-content/uploads/2023/07/image-3-1500x992.png 1500w, https://alaniswright.com/wp-content/uploads/2023/07/image-3-705x466.png 705w, https://alaniswright.com/wp-content/uploads/2023/07/image-3-450x298.png 450w, https://alaniswright.com/wp-content/uploads/2023/07/image-3.png 1740w\" sizes=\"auto, (max-width: 1030px) 100vw, 1030px\" /\u003e\u003c/a\u003e\u003cfigcaption class=\"wp-element-caption\"\u003e\u003cem\u003eOur user journey mapped onto our user lifecycle funnel\u003c/em\u003e\u003c/figcaption\u003e\u003c/figure\u003e\u003c/p\u003e","title":"Tracking our product’s user lifecycle funnel in Google Analytics"},{"content":" Climate Policy Radar’s search tool breaks a critical research barrier by enabling users to search non English law and policy documents, and see English translations of passages that match their search. Effective policies are paramount to tackling climate change. Yet existing data about existing laws and policies \u0026#8211; and which ones work \u0026#8211; are sparse, siloed and not readily accessible. One of the greatest barriers is language: national laws and policies are written in a variety of different languages, providing a considerable challenge for researchers, policymakers, and analysts trying to understand the law and policy landscape. We believe that by enabling users to search the full text of documents originally written in any language, we can help break down barriers between climate law and policy professionals working in different regions of the world. Longer term, we aim to have a multilingual user interface so that users can search the site and view results in different languages as part of our mission to democratise access to national climate law and policy data. This new functionality is one of our most asked for features, and it has proved popular with users of our\u0026nbsp;Global Stocktake Explorer\u0026nbsp;who have had access to translated search matches since June 2023 as part of our work to support the UNFCCC official process this year. How does it work Documents are translated to English using Google’s Cloud Translation API. While the quality of auto-translation does not always capture full meaning and nuance from the original language, we hope that it serves as a first step to improve accessibility and reveals which national jurisdictions are discussing and addressing critical areas of climate action that may have previously gone overlooked. Searching a non English PDF document will show English translations of all the passages that match the search term. These will also be highlighted in the original language PDF document. Clicking on the matches will navigate the user to the place in the document where the match appears. Here is an\u0026nbsp;example search\u0026nbsp;of “flood defence” in the “Adaptation strategy to climate change in the Czech Republic”. Searching a non English HTML document will only show English translations of all the passages that match the search term. Highlights over the full text of the document are not available for HTML documents yet, but you can view the original source document and translate it using Google Translate in your browser. Here is an\u0026nbsp;example search\u0026nbsp;of “marine pollution” in the Vietnamese “Law on Marine and Island Resources and Environment No.82/2015/QH1”. Even though the quality of auto-translation does not always capture full meaning and nuance from the original language, this is a significant step forward in enabling researchers, policymakers, and analysts to uncover the full depth and breadth of national legislation and policymaking underway across the world that may have continued unnoticed. Our plans for the future Introducing this new functionality is the first step as part of our mission to democratise access to national climate law and policy data. In the coming months we are planning to enable people to: Switch between the English and original language version of passages that match a search. This will make the passages easier to find and translations easier to compare. See the full text of the document and highlights, in both English and the original language, for both HTML and PDF documents. This will enable the user to see where the passages appear within the context of the full document. Sign up to be notified\u0026nbsp;when this functionality is available. Longer term, we want to have a multilingual user interface so that users can search the site and view results in different languages. French and Portuguese are the first languages that we would like to support. Check out our\u0026nbsp;public product roadmap\u0026nbsp;to learn more about our plans for the future. Tell us your thoughts We’d love to hear feedback on this feature. If you want to share your ideas, please\u0026nbsp;get in touch\u0026nbsp;or\u0026nbsp;schedule a conversation\u0026nbsp;with us to discuss. This blog post was originally published on\u0026nbsp;Climate Policy Radar ","permalink":"https://alaniswright.com/blog/new-feature-english-translation-of-climate-law-and-policy/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  \u003cstrong\u003eClimate Policy Radar’s search tool breaks a critical research barrier by enabling users to search non English law and policy documents, and see English translations of passages that match their search.\u003c/strong\u003e\n\u003c/p\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  Effective policies are paramount to tackling climate change. Yet existing data about existing laws and policies \u0026#8211; and which ones work \u0026#8211; are sparse, siloed and not readily accessible. One of the greatest barriers is language: national laws and policies are written in a variety of different languages, providing a considerable challenge for researchers, policymakers, and analysts trying to understand the law and policy landscape.\n\u003c/p\u003e","title":"New feature: English translation of climate law and policy"},{"content":" I am working at a startup of 13 people with big plans for the future. Notion is one of the main tools everybody in the team uses. This post describes how we have set up Notion to make information easy to find across multiple growing teams. What is Notion Notion is a note-taking and productivity tool. We use Notion for organising our ideas and documentation keeping track of work We don’t use Notion for: tracking technical work. For that we use Linear file storage. For that, we use Google Drive As you can see from the table below, in most places I have worked before the jobs that I am using Notion to do would have to be done by two separate tools. Job to be done Most places I’ve worked before Climate Policy Radar Tracking work Trello Notion Organising ideas \u0026 taking notes Wiki software (eg. confluence) or lots of linked Google Drive or Microsoft docs Notion Tracking developer tasks Jira, Pivotal Tracker Linear File storage Google Drive or Microsoft Google Drive How we have set up Notion Notion allows you to create two types of pages: Normal pages. These Pages in databases Normal pages include a page title and a flexible drag-and-drop content area. You can insert different types of headings, text, media etc into this content area. You can also embed content from third-party tools, such as a view from Linear. Databases are normal pages with one crucial addition: customisable metadata. For all pages that belong to a database, you can add an unlimited amount of extra metadata fields. These enable users to visualise, filter and sort the database content in a multitude of ways. An example page from the Meeting Notes \u0026amp; Communications database\nHow we use databases Meetings and Communications is one of our main databases. Each page in this database has the following fields: Date (date field): so we know when the meeting happened / or comms got sent Type (select): eg. planning meeting, decision, premortem, weekly sync, 121 Tags (multi-select): optional field used for anything else we might want to tag this by Participants (person): tags all the people who involved in this Links to pages from other databases: eg. any partnerships, bets or actions/questions this meeting or comms relates to Having this content in a database means we can do things like Allow a team member to see notes from all meetings they have attended View all relevant meetings or comms related to a specific product bet or partner Find all content from a specific time period (which will come in handy in the future when we need to archive old content) I have configured my profile page so that I can see a view of every database item that is assigned to me (some data blurred out)\nFrom the start, we have created common databases designed for reuse across the organisation. This means that data science \u0026 operations meeting notes get stored in the same place. If people want to view them separately they can create a view of the database and filter using tags. Some of the main databases we use are Product bets: things we might do that might improve the product (aka product backlog) Actions, notes \u0026 questions: things we need to do, questions we need to answer or documentation of work we have done Meetings \u0026 comms: minutes for meetings, written communications or notes about work Partnerships: third party organisations we are working with, or planning to work with User research: interview summaries, analysis, scripts and planning User research PII database: a restricted database to keep track of sensitive data related to user research Papers: academic and research papers that relate to our work Tools we use: describes what they are, why we use them and how Glossary: words \u0026 acronyms we use along with definitions Team members: a place for everyone to introduce themselves to the team. Also includes a personalised view of all the databases Databases are powerful, but less is more. Having more databases means Viewing/filtering/sorting becomes less powerful, as this can only happen on one database at a time People get confused about which database to find things in The information architecture of the organisation becomes more complex and hard to manage We try to avoid creating new databases unless the benefits of doing so outweigh the cons. How we use templates For each database, I have at least one template. Templates enable me to prefill the page with any useful page elements or prompts at the click of a button. This means: Pages of the same type get structured and formatted consistently with minimum effort Complex links between database pages are mostly handled automatically. Though there is still a need to manually set up some of the links when you create a new page Below is an example template for one of our bets. The template we are using for product bets\nOwnership \u0026amp; structure Below is our top-level Notion structure (with the person responsible for maintaining that section in brackets). Home (operations lead) Comms \u0026 engagement (comms lead) Collaborations \u0026 partnerships (comms lead) Data science (data science lead) People (operations lead) Policy (policy lead) Product (product lead) Technical (CTO) The whole team gets consulted before we make any major changes. We’ve found it useful to have one person responsible for each area so that someone can champion continuous improvement. Public notion pages Notion isn’t just for the team. We can choose to make some pages available to partners or to the public too. For example, Notion powers our public roadmap. We also have a notion database that we use to track all of the work we are doing with LSE which everyone from both organisations has access to. Problems with Notion Overall, I think Notion is a great tool, but not perfect. Here are some of the main problems I’ve found so far: When copying and pasting data between different pages, tables are not copied. They need to be manually duplicated and manually inserted into the correct position on the page. It would be nice if I could select all and copy in the same way as I can on Google Docs or Word. It can be slow to load at times. This may be a downside of having a database-heavy Notion setup. Labels on cards don’t appear in a consistent order on the board view. They appear in the order in which they got added. This can make boards with lots of labels difficult to read. Metadata on databases is super powerful. But every time you open a page in a database, the first thing you see is lots of separate metadata rows. This means you have to scroll a lot before you get to the content of the card. It would be great if Notion found a way to minimise the space this takes up in the UI. Similarly, when you view the metadata on cards in board view, the labels all appear on separate lines. Wrapping separate metadata fields instead of all the content being on a new line could fix this. Our workaround for both of these problems is to minimise the number of metadata fields we have in each database. Thanks for reading I hope you found this useful. Get in touch if you have any feedback. I\u0026#8217;m particularly keen to hear from anyone who knows solutions to any of the above problems! ","permalink":"https://alaniswright.com/blog/how-we-have-setup-notion-to-help-our-startup-stay-organised/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  I am working at a startup of 13 people with big plans for the future. Notion is one of the main tools everybody in the team uses. This post describes how we have set up Notion to make information easy to find across multiple growing teams.\n\u003c/p\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"what-is-notion\"\u003eWhat is Notion\u003c/h2\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  Notion is a note-taking and productivity tool. We use Notion for\n\u003c/p\u003e\n\u003cul class=\"wp-block-list\"\u003e\n  \u003cli\u003e\n    organising our ideas and documentation\n  \u003c/li\u003e\n  \u003cli\u003e\n    keeping track of work\n  \u003c/li\u003e\n\u003c/ul\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  We don’t use Notion for:\n\u003c/p\u003e","title":"How we have setup Notion to help our startup stay organised"},{"content":" We are delighted to share Climate Policy Radar’s Public Product Roadmap \u0026#8211; sketching the steps we’re taking today to reach our (very) ambitious future goals. Transparency is one of our core values, and it threads through everything we do and advocate for. We believe that being open about our own processes and priorities will lead us to make decisions that are rooted in the needs of our users and stakeholders. It will enable us to move, iterate, fail, and retry faster, in the face of the growing climate emergency. Our roadmap is both practical and aspirational. You can use it to track the progress we’ve already made on developing our\u0026nbsp;research tool, what we’re working on now, and what we plan to work on in the future. We’ve set our sights high. Alongside charting the direction we’re taking to achieve our goals, we’ve written a brief description under most items on the roadmap so you can learn more about what the work involves. Organising, analysing and democratising data Our goal is to provide data and tools to support better decision-making. Robust, accessible data equips and empowers policymakers to learn from successes and mistakes and design better policy responses. Data helps track and evaluate collective climate action, as well as contributing to policy risk analyses for mobilising public and private finance. Evidence also helps citizens and civil society hold decision-makers to account through democratic engagement and action. Our work is centred around three strategic pillars that aim to address these systemic challenges: organise, analyse and democratise data. The items on\u0026nbsp;our roadmap\u0026nbsp;are segmented into our broad areas of work against these goals \u0026#8211; traversing from left to right on the map will guide you through what we’ve built all the way to what we’re dreaming about. Below we’ve mapped out our broad plans across these pillars. 1: Bringing in more datasets and documents (on roadmap as “New Data”) We build data pipelines that ingest and translate documents, bringing them onto a single platform to make them easily discoverable and comparable. On our immediate horizon (this year) is widening our data offering by bringing in a range of other datasets. This includes documents from the UNFCCC (for example, NDCs and documents submitted under the first Global Stocktake); climate litigation documents from our partners at the Sabin Center; disaster risk reduction policies (with UNDRR’s Preventionweb); policies about nature-based solutions (with Open Earth Foundation and Arboretica), and more. Beyond that, we’re dreaming of collating state- and city-level documents, and expanding beyond climate to other closely intertwined domains like biodiversity and health. 2: Using AI to derive insights from documents (on roadmap as “Data Science and AI”) Law and policy documents are often long, and dense with data and insight. Because of this, they can be inaccessible and opaque. So as well as making documents accessible, we work to make them useful for policy tracking, evaluation and analysis by extracting structure, meaning and insights from them. To do this we’re applying machine learning and\u0026nbsp;natural language processing\u0026nbsp;to identify key concepts in the text \u0026#8211; for example, the technologies a policy is seeking to accelerate or phase out, the emission reduction targets a country has committed to, or the policy instruments it employs. These concepts are the foundation on which we’re building a\u0026nbsp;knowledge graph, which will string together the concepts identified, and represent a network of connections and relationships between entities, like extreme weather events and adaptation measures aimed to address those. This opens up the ability to explore policy data in detail, and eventually, extend and connect it to other datasets \u0026#8211; like budgets allocated, emissions, deforestations metrics and more \u0026#8211; to start answering the big question of \u0026#8211; what impact do these policies have? We are also building research tools to interrogate the data, including exploring how we can leverage large language models such as BERT and OpenAI’s ChatGPT and\u0026nbsp;GPT-4\u0026nbsp;as virtual research assistants. This includes summarising and comparing text, or generating content maps of documents, as well as data visualisations, time series creation and more. 3: Enhancing our user interface (“User Interface”) Our\u0026nbsp;research tool\u0026nbsp;includes\u0026nbsp;country profiles,\u0026nbsp;semantic search\u0026nbsp;that saves time by recognising and looking for similar phrases to your search term, and a highlighting tool that shows you where your search term or related words appear in the text of documents \u0026#8211; no ‘CTRL+F’ needed. We have many more things in the pipeline to help people get more out of our data. We will make key concepts identified by our data scientists easy to find in a document (eg. ‘show me all the renewable technologies in this document’). Documents from all languages will be automatically translated to English, and longer-term the entire user interface will be made available in other languages too (probably starting with French and Spanish). We will find new ways to allow users to visualise and explore our data, and make structured data available via APIs for others to use. We are thinking of personalised features like saved searches and email alerts. The creation of our law and policy knowledge graph will enable new interfaces for exploring policy insights, and will combine with our experiments with large language models (like ChatGPT) for guiding our users to the information they need. This roadmap is… What we are working on now, and what comes next:\u0026nbsp;We’ve divided this into a few rough time blocks (Live, Building, Designing, Planning, Dreaming) to signal when we anticipate working on each task. Focussed on data and product changes that are user-facing:\u0026nbsp;We don’t include all the under-the-hood functionality for internal users like developers or internal admin systems (for example, policy analysts who add and edit data). A living document:\u0026nbsp;You can visit the link at any time to view the latest version. We’ll also share how our roadmap is progressing and evolving through blog posts and newsletters \u0026#8211;\u0026nbsp;sign up to receive our newsletter. If you’re keen to know more about what we have already done, follow\u0026nbsp;Climate Policy Radar’s Changelog\u0026nbsp;that details our latest product developments. This roadmap is not… Exhaustive:\u0026nbsp;We’re coming up with new ideas all the time, so check back in regularly to see our latest ideas and plans. Set in stone in terms of content or timeline:\u0026nbsp;There is increasing uncertainty as we traverse the roadmap. This is because as we continue to learn and grow, we’ll generate new ideas, respond to feedback, push the boundaries for what’s possible \u0026#8211; and also, no doubt, bump against unforeseen challenges and hurdles. Tell us your thoughts We’d love to hear feedback both on what our users and stakeholders need \u0026#8211; and on how we might go about meeting those needs, from a technological perspective. If you want to share your ideas, wish lists (and dreams!), or any other feedback on this roadmap please\u0026nbsp;get in touch. We’d especially be grateful if you’d be happy to\u0026nbsp;participate in a short user interview\u0026nbsp;with our product manager. This blog post was originally published on Climate Policy Radar ","permalink":"https://alaniswright.com/blog/climate-policy-radar-launches-public-product-roadmap/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  We are delighted to share \u003ca href=\"https://climatepolicyradar.notion.site/8071896b79f540e3b975ff564791ed4a?v=bf5633ead154432ba5dfea6fc435edad\"\u003eClimate Policy Radar’s Public Product Roadmap\u003c/a\u003e \u0026#8211; sketching the steps we’re taking today to reach our (very) ambitious future goals.\n\u003c/p\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  Transparency is one of our core values, and it threads through everything we do and advocate for. We believe that being open about our own processes and priorities will lead us to make decisions that are rooted in the needs of our users and stakeholders. It will enable us to move, iterate, fail, and retry faster, in the face of the growing climate emergency.\n\u003c/p\u003e","title":"Climate Policy Radar launches public product roadmap"},{"content":" At Climate Policy Radar, bets are things we might do that might improve our product. We frame these as problems we need to solve or solution ideas that we think might add value. This post explains how we keep track of bets from initial idea to completion. Most other organisations would probably call this a product backlog, but internally we like to talk about these as bets. Why bets instead of features, improvements or product backlog items? There is lots of uncertainty in product development. When you start out with a problem to solve, you don’t know what the solution will be. And there’s always a good chance that new features won’t have the desired impact. Everyone has a mental model of bets which captures this uncertainty. So to help us keep this uncertainty front of mind, we decided to think of a new feature or product backlog item as a ‘bet’. The bets database All bets go into a Notion database which we have imaginatively named the Bets Database (you might call this a product backlog in your organisation). Notion databases are great because they allow you to filter, sort and view information in an infinite variety of ways. Metadata for each bet Each bet has four metadata fields Status Reflects the stage the bet is in. Most bets evolved from idea \u003e discovery \u003e delivery \u003e done. Possible values include: idea blocked queue for discovery discovery queue for delivery delivery done this week done for previous quarters Tag A dumping ground for all the structured metadata we might want to add. At the moment this includes: what product it is for milestone/project associated with it disciplines involved roadmap category labels we use during standups to flag things as needing discussion Assigned The team member(s) assigned to the bet Linked Actions, Notes or Questions We have a separate database called Actions, Notes \u0026 Questions where we keep track of all the tasks that need doing. Discovery/design activities and stakeholder coordination tasks go here. Developers like to use Linear for tech tasks so we keep those separate. Each action, note or question can link to one or more bets. Template for a bet Once prioritised, bets use the following template: Title A brief statement describing the thing we are doing in the smallest number of words that the team will understand. Titles are sometimes prefixed with a code to make them easier to find Hypothesis statement: All bets start with the statement “IF we solve this problem / deliver this solution THEN we will achieve these positive outcomes”. This keeps us focused on the value we want to achieve Linear / Figma / Whimsical links Once developers start working on a bet, we create a Linear project and link it to the bet. This enables us to quickly switch between engineering tasks in Linear and bet information in Notion. Any associated Figma designs or whimsical storyboards/maps we’ve created are also linked to at the top Notes Notes is a filtered list view of all entries tagged with #Note for this bet in the Actions, Notes \u0026 Questions database. We keep notes in this database because often actions \u0026 questions lead to useful product documentation. We want to minimise the number of different notion databases we have so that information is easier to find. By the end of discovery, most bets have at least 3 notes in them: problem discovery: includes everything we’ve learnt about the problem we are trying to solve solution options: the different options we explored, and why we made the choice we did solution requirements: only includes information about what we have agreed to build Linked databases Actions, Notes \u0026 Questions visualise the work that’s needed on each bet. Meeting notes associated with this bet are also displayed here. The template we use for new bets in our bets database\nWhy we prefer a minimalist approach to Notion metadata and templates We used to have a much more complicated template with lots of different metadata fields and lots of pre-written headings for us to fill in. However, we found that our main use of the bet page was as a container for information. From the bets page, we wanted to quickly access all relevant designs \u0026 documentation, and see a view of all work planned vs in progress vs done. We did not want to have to scroll through pages of metadata and information to find what we were looking for. Different views of the bets database Notion allows you to view databases as tables or lists, but I tend to use the board view for bets (which looks kind of like Trello). The three main views I like to use are ideas, priorities and done. View 1. Ideas This is a dumping ground for ideas which are not currently a priority. The bet template is not used for ideas. Most ideas just include a title and maybe a sentence from the ideator explaining their thinking. The ideas view also includes discovery work. Bets move toward the top as they move from idea \u003e queue for discovery \u003e discovery. I find it useful to view ideas alongside discovery work as I often need to move bets back and forward between these states. Most people don’t look at the ideas board. That’s not a bad thing though. I prefer for people to focus on their priorities! The ideas view of all our bets\nWhy I don’t just delete all the ideas A lot of product managers argue for deleting items from the product backlog when they are not an immediate priority. This is because of the overhead involved in triaging all those extra priorities, and the distraction it causes to the team. These are good points that are worth considering. But I prefer to solve this problem by filtering them out of the priorities view rather than deleting them entirely because: when people have ideas, most people like to write them down somewhere to share them with others. Better to have them all in one place where everyone knows where to find them rather than scattered around in emails, slack messages or random pages on Notion. sometimes bets get deprioritised after some discovery thinking has already happened. I don’t want to see that bet on my priority board, but I also don’t want to lose that information. Tagging it as an idea gets it out of everyone\u0026#8217;s way without data loss. as a product manager, I find it useful to browse all the ideas every few months when we do strategic planning. I make sure they are all tagged by roadmap category (data in, data quality, UX/UI, platform) so that similar ideas are together. The effort required from me to do this is negligible as a team member, it is useful to have a look through the ideas list to get a sense of the types of directions the product might go in the future. This is particularly true of new joiners View 2. Priorities This is for bets prioritised for the current planning cycle. When a bet moves into the discovery queue, I start using the full bet template. The priorities view shows all work on a board view with bets flowing from left to right. Blocked is for work that people can’t start yet even if they have the capacity. This is usually because there is another bet that needs to progress before this one can start. Discovery is where we understand the problem we are trying to solve, ideate solutions and decide on the best one. Discovery is multidisciplinary and involves product, UX design and engineering. At the end of discovery, we know what we are going to build. During discovery, we use the linked Actions, Notes \u0026 Questions database to keep track of actions/questions we need to answer. We keep problem/solution documentation in the same database with a label of “Note”. This means it automatically appears in the notes list at the top. Delivery is where our engineers actually build the thing. We keep track of engineering tasks in Linear. But artefacts like architectural decisions, requirements documents and user story maps live in Notion or Whimsical. Queues exist for discovery and delivery. These are for things that are not yet in progress but are a priority. Queues are an excellent thing to visualise, as having too much work in queues is a form of waste. Done this week shows all work done in the last week. In our weekly team standup meetings, we walk the bets board from right to left, starting with “Done this week”. Not much getting done in a week is a warning sign for us that we are not delivering fast enough. When we walk through the other cards, if it seems like they need a bigger conversation, we add the label “Discuss after standup” and move on to the next card. The priority view of all our bets\nView 3. Done This is for bets that are complete. I have broken up “done” into multiple statuses. These include: done this week (see above explanation) done for all previous quarters. This enables us to keep track of what work we did and when we did it. The view of all completed bets Other views I like to use We have lots of other views too including: priorities filtered by project/milestone or discipline involved. This helps us have more focussed conversations with specific team members a table view of all bets. I mainly use this to search the whole database with no filters applied when I want to do a full database search a filtered view of all bets showing only those assigned to me A view of all the bets currently assigned to me (I can also see anything assigned to be from other databases via the other tabs)\nBreaking bets down into smaller chunks As bets go through discovery, we often decide to break them out into smaller chunks. When this happens, discovery documentation can become fragmented and hard to find. At the moment, we are handling this by moving the initial discovery bet to done breaking it up into smaller chunks prominently linking all the smaller chunks back to the original discovery bet Duplication with Linear The line between engineering work and bet actions can get blurred. It also sometimes feels like overkill to set up a linear project/task for a small bet which might only involve a small amount of engineering work. However, there are lots of things that the bets database is doing for us that it does much better than Linear. And the duplicated effort here is just a few extra clicks. Debatably this is an ok trade-off given the different strengths of both these tools. This is one area I am not entirely happy with in our approach, and we might try to consolidate tools in the future. ","permalink":"https://alaniswright.com/blog/managing-product-backlog-bets-with-notion/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  At Climate Policy Radar, bets are things we \u003cem\u003emight\u003c/em\u003e do that \u003cem\u003emight\u003c/em\u003e improve our product. We frame these as problems we need to solve or solution ideas that we think might add value. This post explains how we keep track of bets from initial idea to completion. Most other organisations would probably call this a product backlog, but internally we like to talk about these as bets.\n\u003c/p\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"why-bets-instead-of-features-improvements-or-product-backlog-items\"\u003eWhy bets instead of features, improvements or product backlog items?\u003c/h2\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  There is lots of uncertainty in product development. When you start out with a problem to solve, you don’t know what the solution will be. And there’s always a good chance that new features won’t have the desired impact. Everyone has a mental model of bets which captures this uncertainty. So to help us keep this uncertainty front of mind, we decided to think of a new feature or product backlog item as a ‘bet’.\n\u003c/p\u003e","title":"How we use Notion to manage our product backlog / bets"},{"content":" 6 months ago, I joined a climate tech startup called Climate Policy Radar as employee #11. As their first product manager, user research is one of the main things I am responsible for. This post describes the approach I am using to gather continuous feedback from users via user tests and interviews. Background For most of the past 7 years, I have worked with organisations that had dedicated user researchers on most teams. For the past 6 months, I have had to wear many hats: UX designer, business analyst, performance analyst, tester, scrum master and of course product manager. User research is something I have only had the capacity to do part-time. So I have developed a light touch approach that fits alongside all the other parts of my job. How we do user research User research helps us answer three questions: Is there a need or opportunity? Do people value my proposed solution? Can people use my proposed solution? There are lots of different ways to do user research, but the main approach we’ve used so far is user feedback conversations. These are 15-45 minute conversations with someone who has used our product or might use it in the future. We’ve had more than 50 of these conversations so far. Our aim is to be doing five a week so we can continuously and rapidly evolve our ideas. Before I joined we also ran a survey with some of our early-access users. As the product manager, I lead most user feedback conversations. But user research is a team sport. Getting the team involved improves the research. It helps us make better decisions about the things we want to learn from users and avoids us having one person as a single point of failure.\u0026nbsp; It also improves the product. When team members learn more about users they build empathy and understanding. These conversations have given us a rich understanding of users and the problems they are trying to solve. This has helped us to focus on building a product that is genuinely useful to them. Now that we have a live product we can also track user behaviour via analytics.\u0026nbsp; As user numbers grow we will start making more use of other methods such as micro surveys and A/B tests. How we find users to speak to When we launched the first (alpha) version of our tool, people had to register for early access. We put a tick box in the form asking if people would be happy for us to contact them. We had about 500 sign-ups for early access, and we spoke to 35 of them \u0026#8211; some before launch, and some after. Now that we have a live product, we invite every user who gets in contact with us to join a user feedback session. This includes people who contact us, submit a law/policy document or who request to download our data. We also do regular shout-outs on social media and across our networks to find people to talk to. Calendly is a great tool that automates the signup process. Through Calendly users can: Find out more about what to expect from a user feedback conversation Find a slot in my calendar that works for them Receive a calendar invite that contains a zoom link and instructions View and complete our consent form This is my first time recruiting research participants without offering incentives. So far so good! Our no-show rates are at 10-15% which is around the industry average. The Calendly link I use to book feedback conversations with users\nHow we use data responsibly We ask everyone to read and complete a short (one-page) consent form before the session. This helps set expectations for how it’ll run and how we handle their personal information. It also asks for explicit consent for: other team members to observe to record the session for other team members to be able to view the recording in the future. Questions we ask Our sessions are usually a cross between a user interview and a usability test. We start by asking people questions about their role and what their work in climate policy involves. This helps us understand who they are and what problems they’re trying to solve. Starting with easy questions like this also helps people settle in and get comfortable. If they haven’t used our tool before, we usually ask them to show us how they use any other tools. This gives us insight into how they are solving problems today.\u0026nbsp; We also observe them using Climate Policy Radar for the first time. This gives us insight into how new users onboard, and whether they understand how it works. If they’ve used it before, we usually ask them to show us how they last used our tool, and about what problems it helps them solve. These conversations focus more on understanding what regular users do with the tool, and how it might grow to better meet their needs in the future. We end by asking users if they have any questions for us and ask if they are willing to participate in further research. We are gradually building up a rich database of users we can go back to for further conversations when needed, which is great. The questions we ask depend on our research priorities at the time. They also depend a bit on the type of user we are speaking to and what direction the conversation goes in. For example, users sometimes sign up for conversations because they want to discuss a specific feature idea that isn’t a priority for us right now. If that happens, I try to learn more about the problem they are trying to solve and how they are getting around that problem today. I also ask for permission to speak to them again when solving that problem becomes a priority for us. Taking notes We have two Notion databases where we store user research findings. Our user research page on Notion\n1. Interview log PII database We store all PII (personally identifiable information) here. This includes raw notes from the observer a link to the recording/transcript (stored in a secure folder on Google Drive) the participant\u0026#8217;s name and contact details whether they are willing to participate in future research. 2. User research database. This is where we store summary information that the whole team can have access to. This includes anonymised information about the participant a one-page summary of the key findings from the conversation a link back to the entry in the Interview log PII database any analysis or planning work Turning raw findings into notes At the end of the conversation, we take 10-15 minutes to summarise the raw notes from 1 into the one-page summary in 2. In the beginning, I put lots of tags on each note and linked them back to product bets so the research would be easier to refer back to later. We stopped doing that because it didn’t seem worth the effort. Notion keyword search makes it easy enough to find which conversations cover which topics. And our one-page summaries make it easy to skim-read for key findings. Maybe as we scale this might be one to revisit, but it is overkill for the size we are at now. This is the template we use to capture notes and summarise findings\nMonitoring interviewer performance To improve our performance as interviewers, we check our performance at the end of each session. In the Notion template we use for taking notes there is a checklist of things that the interviewer should avoid. This includes things like “did the interviewer ask leading questions” and “did the interviewer ask yes/no questions” (both of these things are things interviewers should not do). I borrowed this idea from Build Better Products. How we share learnings We write a one-page summary of every conversation. This includes key insights and opportunities for improvement. These one-page summaries are available for the whole team to view.\u0026nbsp; We adapted our template from this interview snapshot. Every few weeks I share what we’re learning from user research with the team, either via a dedicated session or via a slot at the show \u0026 tell. We generally focus more on the findings that have surprised us or the things that aren’t going so well, as these are the things we expect to learn the most from. I always try to share some of the best snippets from video recordings. It’s really powerful for the team to see people using our tool first-hand. I also make updates to our strategic user insights documentation. These include personas, journey maps and research priorities. Not the only tool in the box We also have to be careful with the conclusions we draw from user feedback conversations. People behave differently under observation compared to real life. In almost every session people have used the filters on our search results page. But we know from analytics that only a tiny percentage of people actually do so. It’s best to use feedback conversations to understand why people do things, not what they do. We use analytics to understand what people are doing with our tool. I’ll be blogging about our analytics setup soon. Thanks Thanks go to Faye Koukia-Koutelaki and Lisa Long, all of whom have provided lots of feedback and advice over the past 6 months. And obviously, credit to the Climate Policy Radar team who have worked with me on all of the above. Feedback is welcome, so if you have any ideas for how we can improve on any of the above then get in touch! ","permalink":"https://alaniswright.com/blog/doing-user-research-as-a-product-manager-in-an-early-stage-startup/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  6 months ago, I joined a climate tech startup called \u003ca href=\"https://climatepolicyradar.org/\"\u003eClimate Policy Radar\u003c/a\u003e as employee #11. As their first product manager, user research is one of the main things I am responsible for. This post describes the approach I am using to gather continuous feedback from users via user tests and interviews.\n\u003c/p\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"background\"\u003e\u003cstrong\u003eBackground\u003c/strong\u003e\u003c/h2\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  For most of the past 7 years, I have worked with organisations that had dedicated user researchers on most teams. For the past 6 months, I have had to wear many hats: UX designer, business analyst, performance analyst, tester, scrum master and of course product manager. User research is something I have only had the capacity to do part-time. So I have developed a light touch approach that fits alongside all the other parts of my job.\n\u003c/p\u003e","title":"Doing user research as a product manager in an early-stage startup"},{"content":" This post provides an introduction to team retrospectives and a guide on how to run them. Intro to retrospectives What is a retrospective? A regular meeting for the team to reflect on past performance and identify ways to improve. Why bother? Good teams continuously improve their product. Great teams also continuously improve how they work together as a team. Retrospectives help teams: Identify actionable ways to improve Make continuous improvement a habit Take collective ownership of their processes and ways of working Recognise each other’s achievements Celebrate good performance Good retrospectives are: Actions focused Done frequently enough so that small gains add up to big wins Not just for figuring out how to improve \u0026#8211; also good to celebrate success or thank each other When to do a retrospective? I like to do retrospectives on a regular cadence so that they become a habit. Generally, I do a retrospective every 2-3 weeks but other options include: At the end of each feature At the end of each iteration After a milestone After an incident How to decide a frequency? Start with any of the above, and allow the team to use retrospectives to change the frequency. Where to hold a retrospective? The team must feel safe to speak up, so it’s important to hold the event somewhere where they won’t get overheard. If in the office, this is one you want to have a meeting room for. Who should take part? All members of the team should participate. People outside the team should usually not attend unless the team are comfortable with their presence. How to run a retrospective There are lots of ways to run a retrospective. These are some suggestions of things that have worked for me in the past. For other ideas, check out: Agile retrospective resource wiki Retromat \u0026#8211; plans for retrospectives Start with the prime directive The purpose of a retrospective is to figure out how to improve, not who to blame. One of the biggest fears people have about retrospectives is that there will be lots of finger-pointing. An event like this will not do little to help the team learn and improve. The team need to feel psychologically safe, or they won’t be able to talk openly about problems. Norm Kerth’s Retrospective Prime Directive helps set the tone for a good retrospective. It is: \u0026#8220;Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.\u0026#8221; Make sure everyone in the team understands this. You might want to read it out at the beginning or stick a copy up on the wall. Definitely do this if your team are new to retrospectives or prone to unhealthy conflict. You will need… If you’re in the office then you will need: A room/space where the team can speak in private Post its \u0026 pens for everyone A stopwatch and clock for the facilitator A copy of the prime directive on the wall If remote, then you’ll need access to an online tool. Trello, Miro, Notion and Whimsical are all tools I’ve used to run retrospectives before. I suggest using a tool your team know how to use. For the instructions below, I’ll assume you are running the retrospective in person. It should be easy enough to adapt to an online tool though. Step 1. Put the categories up on the wall My default categories are: “Good, bad, change, thanks” Others I’ve seen work well include “Start doing, stop doing, do more, do less” “Liked, learned, lacked, longed for” The categories are only there to get ideas out of team members’ heads. So don\u0026#8217;t worry too much about which categories to use, or if people add things to the wrong category. Good, Bad, Change, Thanks. The categories I usually choose to use\nStep 2. Introductions For teams that are new to retrospectives, take time to explain what a retro is, why you are doing it \u0026 the prime directive (all covered above) the scope of the retrospective (what specific time period/process/project phase to focus on?) the structure of the session Step 3. Review previous actions If there are any actions from a previous retrospective, review them at or before this stage. If an action isn’t done, allow the team to decide whether to keep it as an action. I suggest asking people for a simple thumbs up / thumbs down and following the majority. Step 4. Gather feedback Allow each team member 3-5 minutes to write down their thoughts \u0026 observations. Once the time is up, each person should take turns adding their post-its to the wall. Everyone should briefly explain what their feedback is before adding it. Some teams start by reviewing important events from the past iteration to jog people’s memories. If doing a retrospective on a specific topic (eg. deployment process), stick the process up on the wall. Step 5. Group and prioritise Allow everyone to vote on the issues they want to discuss by drawing a dot on the post-it. Dot voting is a very effective way of democratically running a meeting. Some rules I often use with dot voting: limit people to 5 votes each to make them prioritise only allow people to place 1 vote per card to avoid someone voting for one card 5 times As people are voting, group post-its if they are about the same issue. Some people do this as they are adding post-its to the wall, in which case this shouldn’t take long. Once everyone finishes, count up all the votes. Find a way of visualising them in order with the most voted at the top. I usually write the number somewhere prominent on each cluster of post-its. Sometimes I will create a separate ordered list. Step 6. Discuss \u0026amp; Agree Actions Now we are ready to discuss the actions. A good rule of thumb is that the team should aim to spend about half the retrospective focussed on discussing actions. Discuss each card in priority order, and identify actions for each Stay focused on actions. Try to keep them SMART Move on asap if it’s clear there will be no actions Timebox the discussion on each card to 5 minutes If time runs out, take a quick vote on whether to extend by an extra 5 minutes or not Actions should have owners Write their name in the corner of the post-it Step 7. Follow up actions After the retrospective, keep the actions visible to the team. Good places to keep retro actions are on a wall, in a team wiki, or in the team’s task-tracking tool. If the team has a delivery manager or scrum master, they should check in with people after a week or so. This will reduce the likelihood of actions getting forgotten. Tips for facilitators Time guides I estimate you will need 60 minutes for a team of 8 75-90 minutes for large or complex teams I try to make sure at least half the allotted time is for discussion and agreeing actions. If there is a single issue that is too big for the retro, consider arranging a separate workshop to focus on finding a solution. Keep the discussion focused on actions The key output you want from a retrospective is actions. The focus is on continuous learning and improvement. Sometimes teams need to vent about something. This is often a very good thing for the team to do, but not for too long. Allow a little time for venting, but try to steer the team towards actions they can take to make the situation better. Ask: “Are there any actions to take away here, or shall we move on to the next topic”. Getting actions over the line When someone suggests an action, I take the view that “silence = consensus”. I’ll add the action to the actions list, and invite other participants to object. If there’s uncertainty, allow the debate to carry on for a brief period before taking a vote from the team to decide whether to keep the action or not. Actions as experiments Another good way of getting actions over the line is to position them as experiments. Try it out for a few weeks, then decide whether to continue or stop at the next retrospective. Ensure everyone gets heard If quiet people are struggling to get into the discussion, hold space for them and invite them in. If people don’t want to speak up, try speaking to them after to see if you can coach them to contribute more. Don’t worry if nobody prioritises discussing things that are going well This is normal. If you spend too long discussing things in the good column you are not doing it right. Most of the actions usually focus on fixing things that aren’t working. So most of the discussion in the second half of the retrospective usually focuses on that. Consider using a theme Some teams like breaking up the monotony of retrospectives by theming each one. I remember my old manager Rosalyn Vaughan facilitating one with a Game of Thrones theme. The categories were: The Iron Throne (good things) Joffrey Baratheon (could’ve been better/nicer) You know nothing Jon Snow (things we learnt) Winter is coming (things we\u0026#8217;re nervous about) Easy Retro have a good directory of themes if this interests you. ","permalink":"https://alaniswright.com/blog/how-to-run-a-retrospective/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  This post provides an introduction to team retrospectives and a guide on how to run them.\n\u003c/p\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"intro-to-retrospectives\"\u003eIntro to retrospectives\u003c/h2\u003e\n\u003ch3 class=\"wp-block-heading\" id=\"what-is-a-retrospective\"\u003eWhat is a retrospective?\u003c/h3\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  A regular meeting for the team to reflect on past performance and identify ways to improve.\n\u003c/p\u003e\n\u003ch3 class=\"wp-block-heading\" id=\"why-bother\"\u003eWhy bother?\u003c/h3\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  Good teams continuously improve their product. Great teams also continuously improve how they work together as a team.\n\u003c/p\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  Retrospectives help teams:\n\u003c/p\u003e\n\u003cul class=\"wp-block-list\"\u003e\n  \u003cli\u003e\n    Identify actionable ways to improve\n  \u003c/li\u003e\n  \u003cli\u003e\n    Make continuous improvement a habit\n  \u003c/li\u003e\n  \u003cli\u003e\n    Take collective ownership of their processes and ways of working\n  \u003c/li\u003e\n  \u003cli\u003e\n    Recognise each other’s achievements\n  \u003c/li\u003e\n  \u003cli\u003e\n    Celebrate good performance\n  \u003c/li\u003e\n\u003c/ul\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  Good retrospectives are:\n\u003c/p\u003e","title":"How to run a retrospective"},{"content":" Hi.\nI am Alan Wright.\nI have been building digital products since 2008.\nToday, I am a London based product manager building responsible AI tools for decision makers and researchers. In my spare time, I am studying for a MSc in AI at the University of Bath, and am a proud cat dad of 3.\nA brief history of work Alan 2008: Built my first website. Got it to #1 in Google. Boom! 2010: Built v1 of the Ramblers walking route creation tool. 2011: Became an agency digital pm, managing many a small web \u0026amp; ecommerce build. 2014: Launched iOS \u0026amp; Android games with Gameloft: both 4.5* and \u0026gt;5m downloads. 2015: Joined GDS, working on transforming government procurement. 2015: Also started writing this blog. 2016: Joined GOV.UK, the UK Government\u0026rsquo;s flagship website. 2018: Consulting for 3 years at HMPO, Land Registry, Help to Buy \u0026amp; Shared Ownership. 2021: Consulting for 1 year at BBC, on iPlayer metadata and digital group strategy. 2022: 6 months at Cazoo (the ship started sinking the moment I joined. Not my fault!). 2022: Jumped ship to AI climate-tech startup Climate Policy Radar as product lead. 2023: Launched GST1 in partnership with the UNFCCC. 2024: Google.org Generative AI Accelarator attendee. Built responsible AI prototype. 2026: Started a MSc in AI at the University of Bath. I am a bit of a geek. Topics that fascinate me include but are not limited to artificial intelligence, product management, ways of working, personal productivity, digital tools, data science, UX, strategy, economics, politics, the housing market, video games \u0026amp; sci-fi. These are the types of things I write about in my blog.\nConnect with me on LinkedIn if you want to give my content some likes!\nCollaborators Some of the products/organisations I have had the pleasure of working on/with:\n","permalink":"https://alaniswright.com/about/","summary":"Product Lead at Climate Policy Radar. Formerly of GOV.UK and BBC.","title":"About me"},{"content":" Premortems help us identify and reduce risks before they happen. They are a great exercise to run before launching a product or feature. What is a premortem Product teams often use postmortems to understand what caused a problem and how to reduce the risk of it becoming a problem again. Premortems are the opposite. You do them at the beginning instead of the end, and you plan how to stop the worst from happening rather than try to understand why it happened. When to use a premortem Premortems are a great technique to use when: Planning a product launch or feature Starting a new project Forming a new team Benefits Premortems help reduce the risk of failure by: Early identification of risks. This means that the team can take steps to mitigate them before they happen Better identification of risks. Asking people to imagine all the ways that something can go wrong is actually quite fun. Giving people license to think critically generates good ideas, and gives people who might not have otherwise spoken up about concerns encouragement to do so Building shared understanding amongst team members and stakeholders about risks, their impact, likelihood and potential responses How to run a premortem To run a premortem, start with a question for the team to answer. The important thing here is that the question invites participants to think negatively. A question I used recently when planning a new product launch was: \u0026#8220;What could go wrong when we launch the new version of our product and redirect the old domain?\u0026#8221; Some people need time to think before they can generate their best ideas, so share the premortem question at least 48 hours in advance. The premortem starts with everyone taking 5-10 minutes to write down all the things that could go wrong, and give them a score for: Impact if the thing goes wrong Likelihood that it will go wrong The two ways I\u0026#8217;ve done this before are: Mapping everything using post-its on a 2\u0026#215;2 grid (impact and likelihood as the x and y axes) Putting everything in a table in Notion / a spreadsheet, and asking people to select the correct value for impact and likelihood I prefer option 1 if running the event in person, and option 2 if running it remotely. Once everybody has had a chance to brainstorm, run through all the problems \u0026#8211; starting with the highest impact/likelihood, and try to identify some actions you can take to reduce the impact/likelihood. Aim to spend no more than 5 minutes on each one to make sure that you can at least get through the top 10 within the hour. You probably won\u0026#8217;t have time to discuss everything, but if you prioritise the highest impact/likelihood ones, then the ones that are left will be the less important ones. Encourage the team to focus on identifying actions they can take to bring the impact/likelihood down to an acceptable level. Try to minimise the amount of time the team spends debating superfluous things like impact/likelihood scores, as the main priority here is to identify actions the team can agree on. As you go through the list, you will probably start speeding up as duplicates are identified, or you realise that actions which have already been discussed are relevant to more than one risk. At the end of the premortem you should have: A list of scored risks An agreed list of actions to mitigate the risks the team are most worried about The last thing to ask the team to do is to vote for the 5 most important actions of all the ones identified. This gives everyone a quick sense of which actions are the most important to prioritise. At the end of the meeting add the actions to the backlog, so they can be prioritised alongside other work. If you have a risk register, you might want to add any new risks you\u0026#8217;ve identified to that also. Templates you can use A whiteboard template you can use for running a premortem in person or online A notion / spreadsheet template you can use to run a remote premortem\n","permalink":"https://alaniswright.com/blog/how-to-run-a-premortem/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  Premortems help us identify and reduce risks before they happen. They are a great exercise to run before launching a product or feature.\n\u003c/p\u003e\n\u003ch2 class=\"wp-block-heading\" id=\"what-is-a-premortem\"\u003eWhat is a premortem\u003c/h2\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  Product teams often use postmortems to understand what caused a problem and how to reduce the risk of it becoming a problem again. Premortems are the opposite. You do them at the beginning instead of the end, and you plan how to stop the worst from happening rather than try to understand why it happened.\n\u003c/p\u003e","title":"How to run a premortem"},{"content":" OKRs (Objectives and Key Results) are a goal setting system that was popularised by Google. To summarise, the objective defines what you want to achieve and the key result defines how you will measure progress towards achieving the objective. In this blog post, I share my thoughts on how to write good OKRs.\u0026nbsp; I focus on the content of the OKRs themselves rather than what they are or the wider process of creating them. Check the links at the bottom if you want more info about OKRs in general. Most of these learnings come from my time with the Government Digital Service, BBC and Cazoo, so this will probably be more relevant to people in larger organisations with a focus on digital.\u0026nbsp; Writing Objectives The objective defines what we want to achieve.\u0026nbsp; Examples of good objectives include: Speed up X process Sell product Y faster with increased margin Ensure compliance with regulation Z Objectives should be: Inspirational Short, memorable \u0026 easy to understand \u0026#8211; aim for 10 words or less! Outcomes, rather than outputs or solutions Qualitative (or at least they don’t have to be quantitative) Achievable Inspirational Achieving the objective should be something that will get the team out of bed in the morning. What counts as ‘inspirational’ varies by team. Just make sure this is something the team cares about. Short, memorable \u0026amp; easy to understand – aim for 10 words or less! Objectives are meant to quickly communicate what the team wants to achieve, so less words is better Don’t worry if 10 words isn’t achievable. Just make it as short and easy to read as you can Outcomes over outputs Focus on the outcome you want to achieve, rather than the outputs you’ll do to achieve the outcome. Good example: “More efficient planning process across all markets” Bad example: “Enable new planning features in system” Why? The new features won’t matter if they don’t deliver the outcome of making planning more efficient. If you must include an output in an objective be sure that: The team is confident the output is the right thing for them to do to achieve the outcome Explain what the outcome is in the objective title (e.g., do to achieve ) Qualitative (or at least they don’t have to be quantitative) Describe the outcome you want to achieve in a qualitative way.\u0026nbsp; Or at least, don’t think that you have to make your objectives quantitative! Remember that key results define what will be measured, not objectives, so unless quantifying an objective makes sense for other reasons it is not worth doing.\u0026nbsp;\u0026nbsp; It can make sense to include lagging metrics in objectives, where the team assume that achieving all the key results will achieve the lagging metric. For example, if the key result includes some changes in product metrics that together should impact a business metric (e.g., profit) by a specific amount, it might make sense to mention the expected profit change in the objective. Can be achievable within the quarter or longer term Objectives (e.g., “Speed up X process”) might be repeated over multiple quarters (or over whatever other planning cycle you might use in your organisation). That is ok. The important thing is that the key results are achievable within 3 months. That is what tells you whether the objective is met. Ideally, teams should break objectives up into bitesize chunks. But if that makes the OKR less understandable or inspirational, then I would advise against it. Writing Key Results The key result defines how we will measure progress towards achieving the objective.\u0026nbsp; It should be a quantifiable metric that is achievable within a quarter.\u0026nbsp; Examples of good key results include: DAU/MAU up from X% to Y% Average value of secondary products bought by customers up from £X to £Y Questions to ask about each key result Baselined? If we don’t have actual data, can we estimate? Target? What specific target or change are the team aiming for? Measurable? Do we have a data source to measure this? Observable? Can we see the metric move in response to the team’s actions? Impactable? Can the team impact this metric on their own? If not, which teams do they need to work with? And are those teams signed up to working with you on this? A leading indicator? What is the lag between the team’s actions and observing a change in this metric? If it’s more than a week or two, it will be difficult for the team to iterate towards the right solution as the feedback loop will be too slow. Are there any metrics the team can use that have less of a lag? How do you know the key result will deliver the objective? What key results are missing that might be needed to achieve the objective? Key results should usually be product metrics Teresa Torres has written some excellent content on business metrics, product metrics \u0026 traction metrics. To summarise: Business metric = metric that moves the business forward (e.g., increased GPU from retail sales) Product metric = metric that helps us understand if the product is moving the business forward (e.g., customers spend more on secondary products when they buy our product) Traction metric = measures usage of product feature or workflow (e.g., % of customers who add sec.ondary product from \u0026#8220;Add an accessory\u0026#8221; widget on product page) Key results should usually be product metrics because they are: Leading indicators Within the team’s control to directly influence Focussed on outcome that matters to the user, not an output It is ok to use a business metric as a key result if these conditions are met. It is ok to use a traction metric as a key result if the team is confident that increasing the usage of a feature will drive the outcomes they want to see.\u0026nbsp; This can often be the case for a mature product team where the product is well understood.\u0026nbsp; If no product outcome can be achieved within a quarter Questions to ask… How will you know if you delivered the right thing? How will you measure success of the output? What milestone can the team achieve within the quarter? Can that milestone be articulated as an outcome? What outcome could we see once this output is delivered? Examples: Users can solve X problem using our service This defines the problem the product solves for our users, rather than the features we are planning to build Do enough discovery work on problem to make a build/buy decision Rather than just saying “complete a discovery in X” we are being clear about the decision that completing the discovery will enable 4 of 6 teams using new system rather than legacy one Ideally OKRs should focus on the value created for users. But in cases where the team is confident that the thing they have built will deliver value once it is adopted, it can make more sense to use a traction metric like this one. Align OKRs, don’t cascade them Cascading OKRs (where all OKRs link to parent OKRs so that they link like a tree map) should generally be avoided. This excellent Tability post gives three reasons why: If one of the top level OKRs are changed, it means everything below it needs to be re-written too If teams at level N can only write their OKRs if OKRs at the level N-1 are written, then that means a lot of waiting around Enabling teams struggle to use key results as objectives without shoehorning their goals in questionable ways, or adding extra OKRs for them to connect into. That means losing clarity or focus Instead of cascading OKRs, teams should align to the intent of the levels above them Teams should set OKRs that enable them to best contribute to the OKRs of all the levels above them \u0026#8211; especially the company OKRs Some OKRs will link to higher level OKRS directly, others indirectly When aligning, teams will challenge each other to ensure OKRs at all levels work together well as part of a cohesive strategy. Credit for this Image When it is ok to cascade OKRs I have seen some teams and teams of teams work well with cascaded OKRs.\u0026nbsp; This has worked for them because they work in a well understood domain, with a good set of business/product/traction metrics, that are leading metrics, that are within their control to influence autonomously. If you can cascade OKRs like this then that is fine, but don’t feel like you need all OKRs to cascade perfectly. More info I hope you found this post useful! If you are interested in learning more about OKRs I recommend these books / blog posts: Radical Focus What Matters OKR guide GitLab OKR playbook Felipe Castro’s OKR guide) ","permalink":"https://alaniswright.com/blog/writing-good-okrs/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  OKRs (Objectives and Key Results) are a goal setting system that was popularised by \u003ca href=\"https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/\"\u003eGoogle\u003c/a\u003e.  To summarise, the objective defines what you want to achieve and the key result defines how you will measure progress towards achieving the objective. \n\u003c/p\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  In this blog post, I share my thoughts on how to write good OKRs.\u0026nbsp; I focus on the content of the OKRs themselves rather than what they are or the wider process of creating them. Check the links at the bottom if you want more info about OKRs in general.\n\u003c/p\u003e","title":"Writing good OKRs"},{"content":" Makers time and collaboration time are two metrics that I have started using to help teams to measure the amount of quality time they have available to do their best work, and to make improvements over time.\u0026nbsp; In this blog post I explain what they are and when/how to use them. Problems these metrics are meant to solve These metrics were born out of two frustrations I have faced working as a product / delivery manager in various UK public sector organisations: Finding time to meet as a team, or do to things across multiple teams can be hard People often complain about there being too many meetings, and not having enough time to get into a state of flow and do their best work They build upon some of the techniques I shared in my better meetings blog post, and explore how the timing of meetings and the structure of people’s calendars can affect productivity. Makers time What it is Managers like me are happy to break their day up into 30 minute slots.\u0026nbsp; Makers on the other hand need large amounts of uninterrupted time (eg. 2-3 hours+) in order to solve a problem, get into a state of flow and do their best work. When makers are constantly interrupted it reduces their ability to do their best work.\u0026nbsp; See Paul Graham’s blog post on Makers Schedules and Managers Schedules for more info. How to measure it Makers time is a block of time where someone can focus un-interrupted on one task, without interruption (eg. from meetings). The metric is “In the average week, what % of time do team members have available for makers time.”\u0026nbsp; See some of my example calculations below the notes. Here are some guidelines I use to take the measurement: Working as a group with other members of the team to solve specific problems does not count as meetings, and should be included in the definition of makers time (eg. pair/mob programming, developer and designer pairing to solve a solution, kick offs, whiteboarding, problem solving, 3 amigos, canvas board sessions, etc). Arguably some of these could disrupt a makers flow, but I want to avoid the makers time metric disincentivising these activities as they are things most teams I work with should try to do more of Team ceremonies do count as meetings as they are not a time for making things, they are a time for planning For time to count as makers time, it needs to be an uninterrupted block of a minimum of 2 hours. Ideally it should be longer These metrics should be collected for key ‘maker’ roles in the team, such as designers, developers, analysts \u0026 QA. There is no harm collecting it for other roles too (eg. product or delivery), but as those roles are more manager than maker, there is less benefit in doing so Metrics will be probably need to be collected by looking at a 2 or 4 week period (many meetings happen on a fortnightly or monthly cadence, and just looking 1 week at a time won’t pick these up) Lunch time should be excluded from makers time, as this requires context switching See the simplified examples below showing calendars with less and more makers time. Figure 1: A calendar with less makers time Figure 2: A calendar with more makers time\nHow to use makers time? Take some time with each member of the team to understand what commitments they have in their calendar.\u0026nbsp; Taking screenshots of their calendar and overlaying blocks of makers time where it exists is a technique that I’ve found works well, and allows you to come up with an overall makers time score (expressed as a percentage).\u0026nbsp; Once you’ve got the data, you can then have a conversation with the makers about how to improve it, and repeat the exercise in the future to see how things have changed. The three best ways to give people more makers time are: Schedule meetings to happen close to each other (eg. all in one half day). This leaves the rest of the week free for makers to make. This approach also works well with hybrid working as you can do these meetings on the day you are all in the office Schedule meetings to happen close to the beginning or end of the day, or close to lunch time. That way, they cause minimum interruption to potential makers time Remove unnecessary meetings As a maker, you should be encouraged to maximise makers time when scheduling meetings, and to push back on meeting organisers who try to schedule “just a quick meeting” in the middle of an otherwise free afternoon.\u0026nbsp;\u0026nbsp; As a manager, you should be available to help with the above and have difficult conversations on behalf of your makers when needed.\u0026nbsp; As a team, regular meetings like standups, show \u0026 tells, retrospectives and planning sessions should be scheduled at times that minimise disruption to makers time (so all in one chunk, or close to the beginning/end of the day or to lunch).\u0026nbsp; As a team of teams, program or organisation, be mindful of how your meetings can impact makers time.\u0026nbsp; Consider setting aside one half day per week or fortnight for things like all staff meetings, company announcements, show \u0026 tells, or other activities that involve all or some of the teams.\u0026nbsp; Consult with teams to find times that works best for most. And record things so that those for whom the time does not work so well can catch up at a time that works better for them.\u0026nbsp; Not all makers time is made equal People do their best work at different times of day, and some people have flexible working arrangements or other responsibilities (eg. school run). \u0026nbsp; It is important to take all of this into account when optimising calenders for makers time. For example, if most makers on the team like to get their best work done in the morning, it is worth considering doing team meetings at the end of the day.\u0026nbsp;\u0026nbsp;\u0026nbsp; Collaboration time What is it? Cross functional teams deliver value by bringing people together with different capabilities which leads to more effective problem solving and smarter decision making.\u0026nbsp; For this approach to work, teams need time available to collaborate as a team and solve problems together as they arise \u0026#8211; often at short notice.\u0026nbsp;\u0026nbsp; How do you measure it? The metric is: in the average week, how much time do the team have available to collaborate with each other. Collaboration time includes: Team ceremonies (standup, retro, planning, etc) Any time every member of the team is free to work together if needed (they don’t have to use this time, it just has to be available if needed) Two suggested ways to collect this metric: Compare the calendars of everyone in your team. Any time where everyone is free or where the team have time blocked out together counts as team time Maintain a miro board of team activities to calculate it My suggested approach is to take a screenshot of the view of all the calendars compared and annotate it in Miro with collaboration time and potential optimisations. How to use collaboration time? For teams that feel like they struggle to find enough time to work together, I would recommend: Setting aside some time every day for the team to collaborate. Do this at a time which minimises disruption to makers time for most, and that suits the working styles of most people in the team. At the end of standup each day, the team can decide to cancel the collaboration time if it’s not needed. This way, teams have time to collaborate if needed Organise cross team meetings that only involve some team members to happen at consistent times. For example, most organisations I have worked in have communities of practice for each discipline. Once per week all the user researchers get together. At a different time all the product managers get together. And a different time again the developers get together. And so on. If all of these meetings happen at a consistent time each week, team collaboration time will increase. Even for teams that already feel like they have enough collaboration time, this can be a worthwhile exercise as it makes it easier to arrange ad hoc meetings that involve people from across multiple disciplines and teams. See the example illustration below. Figure 3: Aligning community meetings to happen at consistent times\nSome other tips on using makers time and collaboration time Allow teams to choose whether they want to use these metrics or not.\u0026nbsp; They are best used as a part of the toolkit to help teams who think they have a problem with having too many meetings or not having enough time to get their best work done.\u0026nbsp; I have tried this technique out with teams that don’t think they have those problems, and the teams did not got much value from the exercise.\u0026nbsp;\u0026nbsp; The value of these metrics is more in the act of taking the measurement and the conversations it provokes, rather than the result itself.\u0026nbsp; Measuring makers time and collaboration time encourages a switch in mindset towards valuing productive time, and seeing an empty calendar as something to be aimed for and protected rather than as an open invitation for catch-ups. Avoid using this metric at the program level or to compare teams. I briefly toyed with the idea of benchmarking makers time on a few teams every 6 months and using that to indicate how much makers time teams had across a programme.\u0026nbsp; This didn’t work because the act of measuring makers time usually leads to teams making improvements.\u0026nbsp; It is also a very easy metric to game, so if teams are doing it to try to look good to senior management rather than as a tool for them to honestly self evaluate, the value quickly starts to diminish (as is the case with most agile metrics). Use these metrics to put a more accurate economic cost on meetings.\u0026nbsp;\u0026nbsp;A meeting involving 10 people who are charged out at £100 per hour costs £1000.\u0026nbsp; But if that meeting involves developers and designers who are having their productive makers time disrupted, the actual cost of the meeting is much higher.\u0026nbsp; In the example above, a 1 hour meeting in the middle of the afternoon actually costs 4 hours of makers time for each attendee.\u0026nbsp; Onto collaboration time, one of the big benefits of having cross functional teams is that they bring together people with the diverse range of skillsets needed to solve complex problems.\u0026nbsp; If teams don’t have time to collaborate together at short notice, they can’t react to new information as fast, and they risk taking longer to change direction in response to new information than competitors do. Economic arguments like these can be used to persuade others in your organization to take protecting makers time and collaboration time seriously. Thank you for reading this blog post! If you have any feedback contact me on my website or connect with me on LinkedIn or Twitter. Also, shout out to Gavin Cooke who worked with me to develop these ideas. Thanks Gavin! ","permalink":"https://alaniswright.com/blog/metrics-i-use-to-help-teams-improve-the-timing-of-meetings-to-increase-team-health-and-productivity-makers-time-and-collaboration-time/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  Makers time and collaboration time are two metrics that I have started using to help teams to measure the amount of quality time they have available to do their best work, and to make improvements over time.\u0026nbsp; In this blog post I explain what they are and when/how to use them.\n\u003c/p\u003e","title":"Makers time and collaboration time: two metrics that help teams improve the timing of meetings to increase team health and productivity"},{"content":" \u0026#8220;Too many meetings\u0026#8221; is something I\u0026#8217;ve said or heard over and over again in every organisation I\u0026#8217;ve worked.\u0026nbsp; Since lockdown began, this problem seems to have gotten worse for two main reasons: There are more meetings: \u0026#8216;Watercooler\u0026#8217; conversations and informal chats around the team space have been replaced with scheduled video meetings. Meetings are more stressful: Video meetings seem to drain energy more than face to face meetings My team have been experimenting with ways to make our meetings work better for us over the past few months.\u0026nbsp; Below is what we\u0026#8217;ve found has worked for us:\nGuiding principles Minimise the amount of time we spend in big meetings. For most of us, they aren\u0026#8217;t an effective use of time Keep meetings focused on the intended outcome Maximise the work done before and after meetings. Use meetings to focus on areas that genuinely need a big group discussion (e.g., where team members are not aligned) Try to problem solve as a small group (e.g., in pairs or trios) before taking something to a big meeting. If you get stuck on something, reach out to the team for support Our calendars should be organised for makers, not managers \u0026#8211; team members need big blocks of meeting free time to get into flow and get stuff done, rather than half hour blocks here and there We shouldn\u0026#8217;t use meetings to read out documents to each other \u0026#8211; try to send something round for people to read in their own time before Many people generally need time to digest information before they can make meaningful decisions on it Preparing for a meeting Try to send out material in advance for people to read in their own time. Ask people to add feedback in the doc, and use the meeting to discuss anything that people feel need discussion. If it\u0026#8217;s not appropriate to send something out before without first explaining the context: have a brief initial meeting to explain your work, then give people time to absorb in their own time before having a follow up meeting to discuss anything that needs discussion What to put in a meeting invite I\u0026#8217;ve set up a template in my email client that pre-populates meeting invites with these prompts to help me remember to use them each time: Required preparation: any documents that people need to read before they join the meeting. Even if you can\u0026#8217;t share it when you make the invite, it\u0026#8217;s important to let people know that you will be sharing something later Outcome to achieve by end of this meeting: a brief explanation of what we need to have achieved by the end of this meeting Agenda: list of activities to go through in the meeting Meeting lead: this is the person accountable for making sure the meeting is well run, and that actions and decisions are recorded Recording actions \u0026 decisions The meeting lead is accountable for recording actions and decisions Decisions should be captured in an email response to the meeting attendees (if the meeting involves people outside the team) or in a comment on the card in the team Trello board (if it\u0026#8217;s just for members of the team) Actions should recorded in the team Trello board (for you, this will be wherever your team\u0026#8217;s tasks are listed) Regular events for the diary Afternoon meetings: with the exception of our fortnightly planning session, we hold all of our regular team meetings (e.g., standup, retrospective, sprint review) in the afternoon. This is because most of the team like to have their mornings free to focus on their work. We also try to group things on specific days to leave people with as many uninterrupted blocks of \u0026#8216;maker\u0026#8217; time as possible. Team time: this is dedicated time for us to use for sharing of information or discussion. It\u0026#8217;s particularly useful for any time sensitive work that comes up which wasn\u0026#8217;t planned for in our fortnightly planning. At each standup, we decide the agenda for team time the following day. If we don\u0026#8217;t need it, we cancel it (it gets cancelled about 50% of the time). Morning coffee: most team members have struggled with the lack of informal chats around the team space that used to happen with a co-located team. So we have an optional 15 minute slot every morning for people to check in and discuss what they\u0026#8217;re working on in a less structured way. We also have an active Teams chat where team members are encouraged to reach out to each other if they want help or are looking to collaborate on something. In summary There\u0026#8217;s nothing complex or revolutionary here.\u0026nbsp; These are all well known practices that often aren\u0026#8217;t applied with enough discipline.\u0026nbsp;\u0026nbsp;They probably apply to co-located teams too.\u0026nbsp; But, because remote meetings are harder, being 100% remote has made it even more important to get basics like these consistently right.\u0026nbsp; And so far so good! Since we’ve started consistently using these practices, team feedback during retrospectives has been positive and we’ve been more consistently delivering on our goals each sprint. ","permalink":"https://alaniswright.com/blog/better-meetings-for-remote-teams/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  \u0026#8220;Too many meetings\u0026#8221; is something I\u0026#8217;ve said or heard over and over again in every organisation I\u0026#8217;ve worked.\u0026nbsp; Since lockdown began, this problem seems to have gotten worse for two main reasons:\n\u003c/p\u003e\n\u003cul class=\"wp-block-list\"\u003e\n  \u003cli\u003e\n    There are more meetings: \u0026#8216;Watercooler\u0026#8217; conversations and informal chats around the team space have been replaced with scheduled video meetings.\n  \u003c/li\u003e\n  \u003cli\u003e\n    Meetings are more stressful: \u003ca href=\"https://news.stanford.edu/2021/02/23/four-causes-zoom-fatigue-solutions/?gclid=EAIaIQobChMIpvTbgMDb7wIVCcDICh1VxQuMEAAYASAAEgIeUfD_BwE\"\u003eVideo meetings seem to drain energy\u003c/a\u003e more than face to face meetings\n  \u003c/li\u003e\n\u003c/ul\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  My team have been experimenting with ways to make our meetings work better for us over the past few months.\u0026nbsp; Below is what we\u0026#8217;ve found has worked for us:\u003cbr /\u003e\n\u003c/p\u003e","title":"Better meetings for remote teams"},{"content":" Show \u0026 tell is a chance for teams to show their work to stakeholders and to get feedback. It\u0026#8217;s a crucial form of governance for agile teams that keeps everyone up to date by allowing them to see the team\u0026#8217;s progress firsthand. Before you read this, you might want to check out my other blog post on how I distinguish between show \u0026 tells, sprint reviews and showcases so that we’re speaking the same language. In this blog post, I\u0026#8217;ll share some tips on running effective show \u0026 tells. Before you start Make sure people understand what show \u0026 tell is and why they should attend. Mark Dalgarno has written this useful boilerplate that you might want to add to your meeting invites. Senior stakeholders in particular should understand the importance of the event and why they should attend. Invite the right people. That\u0026#8217;s anyone with an interest in or influence on your team\u0026#8217;s work. Consider inviting people from elsewhere in Government too. Find the right time. Make sure it doesn\u0026#8217;t clash with any important meetings that are happening which people need to attend. Keep a look out for one off or new events that might stop people from attending. Avoid Mondays and Fridays \u0026#8211; they often fall victim to long weekends or bank holidays. Ensure there\u0026#8217;s a good remote setup. Not such a concern in the age of Covid, but when we do eventually return back to offices it\u0026#8217;ll be even more important to get the experience right for people in the room and attending remotely. Consider booking out a dedicated meeting space and investing in some professional kit to improve the audio visual experience \u0026#8211; including a portable mic for people to ask questions with. Here\u0026#8217;s one example of a decent remote setup you can try. Consider grouping show \u0026 tells which similar groups of stakeholders need to attend. Most busy stakeholders I\u0026#8217;ve worked with prefer to watch 3 show \u0026 tells back-to-back then to have 3 x 30 min meetings at random times throughout their week. This also makes sense if you\u0026#8217;ve got a special room or kit for show \u0026 tells as it means you only have to set up once instead of thrice. Collaborate with other teams who are talking to similar stakeholders as you are to see if you can coordinate diaries. On a recent show \u0026 tell we had 4 teams presenting at the same event. Make sure you\u0026#8217;ve got something to show that attendees will find interesting. If you don\u0026#8217;t have much or anything to share then consider skipping that occurrence. Let attendees know that you\u0026#8217;ll have lots of valuable work to share in the next one. This advice is controversial, as agile teams should always have something valuable to show at the end of each iteration. But sometimes that doesn\u0026#8217;t happen, or the work is too technical to interest most stakeholders, or there’s too little to share to warrant doing a dedicated show \u0026 tell for. In those cases, it may be best to give stakeholders their time back rather than risk wasting their time and having them lose interest in the event. Presenting is a performance, so it\u0026#8217;s worth putting in some time to prepare for it. Plan who will be chairing/speaking, the transitions between speakers, the use of technology, setup of the room and the best order to put things in. On one programme the leads from each team would meet a day or two before each show \u0026 tell to plan the event. Encourage different team members to present their work rather than always relying on the team lead to do the talking. Consider writing some speaker notes or doing a rehearsal, particularly if you are not a confident presenter or planning to demo technology. Check out these tips on doing good presentations. Running the event Hit the record button. That way anyone who can\u0026#8217;t attend can watch it in their own time. Be sure to let everyone know you\u0026#8217;re recording the event before you start. Start with some context. Provide a high-level overview of your team\u0026#8217;s mission and goals, and what the agenda is for the event. Ensure that no personally identifiable information is shared in anything you share. Be honest about things that didn\u0026#8217;t work out as you expected. Mistakes are the greatest source of learning for an organisation \u0026#8211; and show \u0026 tell is an excellent forum to share learning with others. This is especially important in organisations that are new to agile ways of working, as seeing others talk openly about failure in a positive way can help create psychological safety and encourage a more open working culture. Show the thing. One time I was presenting my slides only to see a developer hold up a post-it which read \u0026#8220;more show, less tell\u0026#8221;. It was a bit of a passive aggressive thing to do, but he was right. Try to show the work rather than just talk through slides. Show working code, demo the prototype or visualise some data. People usually find that more interesting than slides alone. Show the users using the thing. Rather than reading through slides of what users said, show some video recordings of your users in interviews or product testing. There\u0026#8217;s nothing like watching a user get frustrated with your service to get stakeholders to realise there\u0026#8217;s a problem. Be sure to anonymise any personally identifiable information if you do this. Consider pre-recording demos. If you\u0026#8217;re worried about technology going wrong, one option is to pre-record a demo and show the video. Just be sure to check that the video works for all attendees \u0026#8211; remote and in person! Find interesting ways to present inaccessible topics. One of the best show \u0026 tells I\u0026#8217;ve seen was from a devops team who used the \u0026#8220;Have I got news for you\u0026#8221; missing words format to explain what they had been up to. The team asked the audience to guess the missing words, with the completed sentence explaining how the new cloud platform was enabling what other product teams were trying to deliver. Explain why it matters. How does the work you are sharing benefits your users and your organisation? Make sure that there is time set aside for questions \u0026#8211; ideally around 50% of the time. One of the main points of sharing this information in the first place is to get feedback, so don\u0026#8217;t just talk at people until you run out of time. Find ways to keep people engaged. Some people like to make comments in the chat rather than verbally. This can be off-putting for the presenter, but on balance I think it\u0026#8217;s a positive thing as it is engagement with the audience. Other members of the team should pitch in to the chat to answer questions or to alert the presenter if someone has their hand up or has asked something pertinent, as presenters won\u0026#8217;t always be able to see the chat + the slides + any speaker notes they have. This is a good activity for the chair to be responsible for. If there isn\u0026#8217;t a culture of asking questions in your organisation, encourage friendly stakeholders to speak up. Consider planting some questions with friendly audience members to get the ball rolling. Straw polls are another effective way of keeping people engaged and get instant feedback. I sometimes use these to ask questions like \u0026#8220;Would you like to see more or less of X at the next event?\u0026#8221; or \u0026#8220;which times work best for future events?\u0026#8221;. This works well with Microsoft Teams where people can respond with Emojis. Don\u0026#8217;t let a single question take over the show \u0026 tell. Discussion is good. But if discussion about a niche topic goes on for too long, then take it offline to be discussed with a smaller group. Use language people understand. Lots of the people in the audience won\u0026#8217;t understand some agile or digital terms, so try to put things into plain English. Avoid using acronyms. A delivery lead on GOV.UK used to put her hand up and ask \u0026#8220;what does that mean\u0026#8221; every time someone used an acronym in a presentation. It helped presenters to get into the habit of using language that people understand. This is a good habit for leaders to adopt. After it\u0026#8217;s done Provide your contact details and invite people to chat to you after the event. Some people don\u0026#8217;t like to speak out in front of others \u0026#8211; you need to make sure they know you\u0026#8217;re open to feedback. Send an email to everyone on the invite with a link to the recording and to your slides. You might find that some stakeholders who couldn\u0026#8217;t make the event will respond to your email at obscure hours with their feedback. Ensure your slides are stored in a folder accessible to everyone in your organisation. Upload the recording of the show \u0026 tell to your team\u0026#8217;s wiki. That way it\u0026#8217;s easy for people to find. This is something the Programme Support team do for me after each event. Follow up on any questions that arose that couldn’t be answered on the day. Metrics for success\nYou know that your show \u0026 tells are working well when: Attendance is consistently high or growing People are engaging with the team Stakeholders tell other stakeholders to attend the show \u0026 tell Thanks to Steffen Lydum and Gethin Jones for their feedback on this blog post! Check out some of my other posts How to run a retrospective How to run a pre-mortem ","permalink":"https://alaniswright.com/blog/running-effective-show-tells/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  Show \u0026 tell is a chance for teams to show their work to stakeholders and to get feedback. It\u0026#8217;s a crucial form of governance for agile teams that keeps everyone up to date by allowing them to see the team\u0026#8217;s progress firsthand.\n\u003c/p\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  Before you read this, you might want to check out my other blog post on \u003ca href=\"http://alaniswright.com/blog/show-and-tells-sprint-reviews-and-showcases-whats-the-difference/\" data-type=\"URL\" data-id=\"http://alaniswright.com/blog/show-and-tells-sprint-reviews-and-showcases-whats-the-difference/\"\u003ehow I distinguish between show \u0026 tells, sprint reviews and showcases\u003c/a\u003e so that we’re speaking the same language.\n\u003c/p\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  In this blog post, I\u0026#8217;ll share some tips on running effective show \u0026 tells.\n\u003c/p\u003e","title":"Running effective show \u0026 tells"},{"content":" I was recently asked to share some best practice on running effective show and tells. This led me into a semantic rabbit hole on the differences between show \u0026 tells, sprint reviews, team reviews, end of iteration reviews, sprint demos and showcases. These words are often used interchangeably to describe similar things. In this post, I’ll explain what some of these terms mean to me. For most agile teams I’ve worked on in Government, all these terms are generally used to describe two different types of events: team reviews and show \u0026 tells. Team reviews are for the team to review the work they have done in the most recent iteration. Also known as sprint reviews in Scrum, these events are held at the end of each iteration. They are a forum for the team to inspect the outcome of the sprint and collaborate on what to do next. All completed work from that iteration should be demonstrated and if necessary discussed. Key stakeholders sometimes attend team reviews. On one team, whilst we worked on our MVP for private beta, decision makers from policy, legal, risk, security \u0026 data protection all attended so that they could see for themselves how acceptance criteria and definitions of done had been implemented. The SCRUM guide states that this event should take up to 4 hours for a 4 week sprint, but I’ve never been involved in team reviews that have lasted longer than 90 minutes. I like to set aside time after standup each day so that the team can review work together as it’s completed rather than all at the end, so my team reviews rarely last longer than 55 minutes. Show \u0026 tells are for the team to show their work to a wider group of stakeholders and to get feedback. They are a crucial form of governance for agile teams that keeps everyone up to date by allowing them to see the team\u0026#8217;s progress firsthand. They are also a forum for celebrating progress and the achievements of the team. The audience at show \u0026 tells is much wider than team reviews \u0026#8211; including any stakeholders with an interest in or influence over the team\u0026#8217;s work. There\u0026#8217;s usually a lot of people in attendance, many of whom are non-technical and/or senior. They are usually held once per iteration, but can also be run less frequently, and are always held after the sprint review. I try to ensure that show \u0026 tells don’t last longer than 55 minutes. I like to group show \u0026 tells according to workstreams or themes to make it easier for all relevant stakeholders to attend each time, so there can be multiple teams presenting in one show \u0026 tell. Instead of walking through every item in the backlog, I find this wider group gets the most value out of seeing specific pieces of work that we think will be most interesting and/or useful to them, and the most likely to generate valuable feedback that will enable the team to validate their learning. I meet with the leads from each team presenting at show \u0026 tell beforehand to plan what we think those things are and how they will be delivered. Combining team reviews and show \u0026 tells into a single event can be a good move when: The team is using Kanban or running continuous reviews of each deliverable throughout the iteration rather than one big review at the end. In these cases, the team will already have had a chance to review the work before show \u0026 tell, so a separate team review may be unnecessary. The team is not part of larger organisation or programme of work. In this case, there might not be enough extra people at the show \u0026 tell to warrant holding a separate event. The team is working in a high trust environment. In this case, team members should feel more able to share work in progress with the wider organisation with less fear of reputational damage if they show a bad piece of work / talk about it in the wrong way. My preference is for the team to review work before it’s shared outside the team, but the main person who needs to be sighted on things is the product manager. Showcases are one off or less frequent events where teams (or teams of teams) share their most important achievements and plans for the future. On GOV.UK we used to do these at the end of each quarter. They usually consisted of some combination of quick overviews from each team, deep dives into the work of specific teams and presentations from leadership or third party teams / organisations. Showcases can be for internal stakeholders, external stakeholders, or both. To summarise, the most important part of all this is that teams should aim to share their work regularly with each other and stakeholders, and get feedback. As with everything in agile, teams should continuously improve their ways of working and do what works best for them and their stakeholders. It doesn’t really matter how many different types of events you run or if you use the same words for things as I do, but it is important for teams within an organisation to describe things in a consistent way. People communicate more effectively when they have a shared language for things. Thanks go to Steffen Lydum and Gethin Jones for their feedback on this blog post! Check out some of my other posts How to run a retrospective How to run a pre-mortem ","permalink":"https://alaniswright.com/blog/show-and-tells-sprint-reviews-and-showcases-whats-the-difference/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  I was recently asked to share some best practice on \u003ca href=\"http://alaniswright.com/blog/running-effective-show-tells/\" data-type=\"URL\" data-id=\"http://alaniswright.com/blog/running-effective-show-tells/\"\u003erunning effective show and tells\u003c/a\u003e. This led me into a semantic rabbit hole on the differences between show \u0026 tells, sprint reviews, team reviews, end of iteration reviews, sprint demos and showcases. These words are often used interchangeably to describe similar things. In this post, I’ll explain what some of these terms mean to me.\n\u003c/p\u003e","title":"Show \u0026 tells, sprint reviews and showcases – what’s the difference?"},{"content":" In this blog post, I explore how assigning economic values to objectives can help organisations and teams make more effective prioritisation decisions. Organisations start initiatives to help them achieve strategic objectives. They often produce tables like Table 1 below to aid in prioritisation and ensure they have a balanced portfolio of work. Table 1 indicates that initiative 1 is more valuable than 2, that 2 is more valuable than 3. It follows that they should be prioritised in that order. This is based on the assumption that all objectives are of equal value. In my experience, this is rarely the case. In Table 2, each objective has been assigned a: money value, which represents an estimate of how much benefit it could deliver to the organisation per annum once delivered. Benefit could include more profit, cost reduction or social benefit (if you’re in the public sector or a charity). percentage value indicating the contribution of each initiative to achieving the objective. This doesn’t have to be exact. A rough indication of contribution is all that’s needed. Table 2 gives us a very different result. Initiative 3 is more valuable than 2 (by quite a lot), and 2 is more valuable than 1 (marginally). Putting numerical values on the value and alignment of initiatives to strategic objectives has two main benefits: Benefit 1. It enables more effective prioritisation decisions. The new data provided by table 2 has reversed the priority order of the initiatives. It’s also clear what the difference in value is between them. Initiative 3 is about as valuable as the other two combined. There will probably be some objectives that are 10 or even 100 times more valuable than others, and the more people in the organisation that know this the better. If teams understand these differences in value, they will be able to make more effective trade off decisions between competing priorities and local decision making will become more effective. Benefit 2. Opening up information improves the accuracy of the information. Teams are enabled to understand what value the organisation has attached to an objective, how it was estimated and how much of that objective they are expected to achieve. So as they learn more about the problem they’re trying to solve and what benefits they expect to deliver, they can challenge assumptions and feed information back up to the leadership team. More accurate information leads to even more accurate prioritisation decisions. What if you don’t know what each objective is worth? Make an educated guess. Be transparent about how you made the estimate so that others can understand, build on and challenge your assumptions. Even if your estimate is wrong, it will still be more accurate than making no estimate at all. Interested in learning more? Joshua Arnold’s post on\u0026nbsp;prioritising work across multiple teams\u0026nbsp;is more thorough than this one. Give it a read! ","permalink":"https://alaniswright.com/blog/not-all-objectives-are-created-equal/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  In this blog post, I explore how assigning economic values to objectives can help organisations and teams make more effective prioritisation decisions.\n\u003c/p\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  Organisations start initiatives to help them achieve strategic objectives. They often produce tables like Table 1 below to aid in prioritisation and ensure they have a balanced portfolio of work.\n\u003c/p\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  \u003cimg loading=\"lazy\" decoding=\"async\" width=\"600\" height=\"189\" class=\"wp-image-406\" style=\"width: 600px;\" src=\"http://alaniswright.com/wp-content/uploads/2019/06/table1.png\" alt=\"\" srcset=\"https://alaniswright.com/wp-content/uploads/2019/06/table1.png 761w, https://alaniswright.com/wp-content/uploads/2019/06/table1-300x95.png 300w, https://alaniswright.com/wp-content/uploads/2019/06/table1-705x222.png 705w, https://alaniswright.com/wp-content/uploads/2019/06/table1-450x142.png 450w\" sizes=\"auto, (max-width: 600px) 100vw, 600px\" /\u003e\u003ca href=\"http://alaniswright.com/wp-content/uploads/2019/06/table1.png\"\u003e\u003c/a\u003e\n\u003c/p\u003e\n\u003cp class=\"wp-block-paragraph\" id=\"caption-attachment-406\"\u003e\n  Table 1 indicates that initiative 1 is more valuable than 2, that 2 is more valuable than 3. It follows that they should be prioritised in that order. This is based on the assumption that all objectives are of equal value. In my experience, this is rarely the case.\n\u003c/p\u003e","title":"Not all objectives are created equal"},{"content":"Healthy teams, happy people and mature agile ways of working are good leading indicators of organisational success. Getting these things right is key to unlocking long term sustainable delivery of value. In this blog post, I summarise some of the approaches I have used to measure and improve ways of working.\nTeam health checks (Spotify style) Spotify’s health check model is a structured retrospective which helps teams and management spot problems and identify where to focus improvement efforts. Teams are asked a set of questions, and each team member answers with a green, amber or red card to indicate their response. This health check model is great because it encourages the team to have focussed conversations about how they can improve, and provides quantitative data which can be used to spot patterns and trends. I like to:\nrepeat every 2-3 months encourage teams to facilitate for each other, so that the usual facilitator can participate openly record the results, so trends between teams and over time can be spotted collaboratively create a set of questions that relate to the context of your organisation rather than reusing the Spotify ones Anonymous surveys When managing a programme, every two or three months I like to use a tool like Survey Monkey or Google Forms to run a brief anonymous survey. As with healthchecks, this provides useful quantitative data indicating whether things are getting better or worse over time. It also provides brutally honest and open feedback that managers might otherwise not hear. I like to:\nrepeat every 2-3 months not include too many questions. Five is plenty. Less is more. use a score system like yes/no or strongly agree/agree/neutral/disagree/strongly disagree. repeat some key questions so you can see trends over time. A good one to repeat is “ Would you recommend working here to a friend?”. have an optional freeform comment box at the end where people can tell you what they think. keep results anonymous, but proactively encourage everyone to respond. review the results and comments with the management team. Agree actions in response. take the time to present the results back to the teams. Communicate the response and actions. Ways of working prompts In my first delivery manager role, my then line manager Ros Vaughan suggested I review the health of my team using David Lowe’s health check template. I recorded my answers to each question and reviewed the results with Ros in our 121s. This activity was useful because it helped me see what good looks like and where improvements might need to be made. It also gave structure to our 121s. As an individual looking to identify ways for your team to improve, give this template a try. As a programme or community of practice, consider creating your own ways of working prompts for use with teams. It can be a great tool which encourages people to ask the right questions of themselves and each other.\nDelivery metrics Delivery metrics give us an idea of how frequently and effectively teams are delivering value. This information can be used to drive process improvements and inform planning activities. Some good metrics to monitor are cycle time, lead time, cumulative flow and cost of delay. Be careful with delivery metrics – measuring some things can cause dysfunctions (as discussed in this post on crappy agile). Be particularly careful with velocity.\nThere are some good tools out there that can automate the collection and display of delivery metrics. If using Trello, try out Corrello. It provides all of the above metrics and more in an easy to use interface. Jira does most of the above out of the box. Alternatively, if you’re tool agnostic, check out Emily Webber’s Kanban Spreadsheet.\nDelivery folk should regularly use these metrics as a basis for conversation with the team during retrospectives and planning. And senior delivery folk should use these metrics as a basis for conversations in regular 121s.\nTechnical delivery metrics Technical delivery metrics help us understand the maturity of development practices, identify areas that need improvement and measure improvements over time. The 2018 State of DevOps Report suggests some indicators of technical maturity which include: deployment frequency and time to deploy % of automated vs manual work in configuration management, testing, deployments and change approvals time to restore service change failure rate time spent on new work vs unplanned \u0026 rework vs support vs fixing defects identified by end users vs remediating security issues Encourage developers to decide amongst themselves which metrics indicate healthy development practices, and take the time to configure a dashboard which gives everyone on the team access to this type of information. As with the delivery metrics, technical folk should review these metrics regularly, look for areas that need improvement and celebrate successes.\n","permalink":"https://alaniswright.com/blog/measuring-and-improving-ways-of-working-on-digital-teams/","summary":"\u003cp\u003e\u003cspan style=\"font-weight: 400;\"\u003eHealthy teams, happy people and mature agile ways of working are good leading indicators of organisational success.  Getting these things right is key to unlocking long term sustainable delivery of value. In this blog post, I summarise some of the approaches I have used to measure and improve ways of working.\u003c/span\u003e\u003c/p\u003e","title":"Measuring and improving ways of working on digital teams"},{"content":"Over the past year I’ve been learning a lot about cost of delay. In this blog post I explain what I’ve learned so far, and how it can be used by teams to prioritise work. My focus is on teams that are following the UK Government Digital Service Standard, but it can be of use to any team.\nWhat is cost of delay? There are always so many things that need doing, but it’s not possible to do them all. Teams need a way of deciding what to work on next, and managers want to be confident that teams are making the right decision.\nCost of delay is a simple measure that factors in value and urgency. When a cost of delay is given to all opportunities it enables more effective prioritisation decisions – and more effective communication of those decisions. An opportunity with a high cost of delay should be done sooner, because there is high benefit to be gained from prioritising it.\nHow to calculate cost of delay Cost of delay = Value * Urgency\nThere are two key parts to cost of delay:\nValue. What benefit could this opportunity deliver for your organisation or your users? In Government this means reducing costs, avoiding future costs, or saving time / money for citizens, businesses and other users. Urgency. Something is urgent if doing it later reduces its total value (eg. if it’s needed for a specific date, or if a competitor might get there first otherwise)\nIn the example below, option 2 is higher priority because the cost of delay is higher.\nCost of delay Value (per year) Urgency Option 1 £1,000,000 £1,000,000 1 Option 2 (best) £1,500,000 £750,000 2 CD3 (Cost of delay divided by duration) CD3 (Cost of Delay Divided by Duration) = Value * Urgency / Duration\nWhen prioritising work, it makes sense to factor in how much time it will take from the team to deliver the opportunity – the duration. This gives us cost of delay divided by duration – which can be abbreviated to CD3 (CDDD).\nIn the example below, option 1 is higher priority because the cost of delay divided by duration is higher. Opportunity CD3 (Cost of delay divided by duration) Cost of Delay Value (per year) Urgency Duration (months) Option 1 (best) £500,000 £1,000,000 £1,000,000 1 2 Option 2 £375,000 £1,500,000 £750,000 2 4 My experience of using relative values When I first started out with cost of delay I used relative values. Working in the public sector where profit isn’t a motive, I assumed that trying to put a £ value on opportunities would be too difficult to do. So I took what I knew of relative estimation for story points and got the team to give each opportunity a score for value, urgency and duration, then plugged those scores into a formula to give me my cost of delay. This in itself was a valuable activity – it got the team talking about value and quickly gave us an idea of what the best opportunities were. But it didn’t scale well to anyone outside the team, or team members who weren’t present for the discussion over value. It was also too easy for the scores to get influenced by the opinions of opinionated and influential individuals who others were only too happy to defer to.\nI also used and created more complex models where opportunities were given scores for their alignment to various strategic objectives and the risk/complexity of delivering them. Answer 10-15 questions for each opportunity and out pops a score that tells you the cost of delay. I’ve created these models myself and used ones provided by consultants. None have worked for me – it’s much better to prioritise using a simple model that everyone gets then it is to create a score that people don’t understand or trust. Donald Reinertsen came to similar conclusions in his book ‘Managing the Design Factory’.\nWhy I prefer to calculate cost of delay in £ It isn’t actually that hard to put £ numbers on benefits. Start with an educated guess. For example, if you’re developing a new feature that will save each user 10 minutes per transaction, there are 100,000 transactions a month, and your user’s time is worth £15 per hour, then the potential benefit to users of that feature is £250,000 per year. Admittedly, some things such as enablers (foundational work that needs doing before user facing services can start delivering value) and information (discoveries and alphas are all about learning rather than delivering user value) are hard to put a value on, but it is still possible. The key thing is to write down the assumptions behind the numbers so that they can be challenged or validated by others.\nAssumptions identified. Once you’ve made your educated guess, you can start validating some of the assumptions behind the guess. Will the new feature really affect all of those 250,000 transactions? Will it really save 10 minutes per transaction? Is your user’s time really worth £15 per hour? These are all things for the team to explore further.\nScales better. Relative estimates struggle when there’s lots of options to compare, or those who weren’t involved in assigning the estimates want to understand them. By visualising all of our assumptions it’s easy for those outside the team or new to the team to understand the reasoning behind the value of work. And by putting £ values on every benefit in a consistent way, it’s easy to compare opportunities within and across teams.\nIncreased accuracy. Sharing assumptions makes information more transparent, and enables more people to provide constructive feedback which can help improve the accuracy of estimates. The act of putting £ values on benefits also helps us overcome cognitive bias and better understand the true value of something. I’ve seen cases where relative estimates assigned two opportunities the same value score, but when the cost of delay was calculated in £ one was 10x the value of the other. It was an eye opener for me.\nGets benefits prediction started. Benefits prediction is an inescapable part of working on any Government project. In many teams, trying to quantify benefits is an afterthought. They struggle to predict what benefit their work will deliver, and they struggle even more to evidence that those benefits have been realised. Using cost of delay to prioritise brings conversations about benefits forward, and gives them extra significance. Early visualization and validation of assumptions puts teams in a better position to estimate and evidence benefits. These estimations can and should be refined as the team progress. This compliments the service manual recommendations on measuring the benefits of your service.\nWhen cost of delay is useful Pre-Discovery Pre-Discovery, cost of delay can be used at a very high level to identify the problem space that the team should be focusing on.\nLook for areas where:\nvolume of users / transactions is high the organisation and users are experiencing a lot of pain the team have the capability to make an improvement value of benefit decays over time (high urgency) During Discovery \u0026amp; Alpha A key output of Discovery is to recommend which opportunities the team or organisation should pursue in the future. For each opportunity considered, try to estimate the cost of delay \u0026amp; how long each would take your team to deliver. Make educated guesses about the values of each. Visualise your guesswork. Show your working and share with others to give them a chance to challenge assumptions. The tables below show how you might communicate benefits \u0026amp; assumptions for each opportunity, and compare the cost of delay across different opportunities. This is explained more at the end of this blog post.\nThe table below shows how to record benefits \u0026amp; assumptions for an opportunity\nBenefit type Value Assumptions Total £3.224m External £1.174m 1,000,000 transactions * 90% take-up * 10 minutes * £7.83 p/h citizen rate External £0.54m 1,000,000 transactions * 90% take-up * 60p postage saving Internal £1.5m 1,000,000 transactions * 90% take-up * 5 minutes * £20 p/h staff rate The table below shows how to compare the cost of delay of different opportunities. Option 3 should probably be done first.\nOpportunity CD3 (Cost of delay divided by duration) Cost of Delay Value (per year) Urgency Duration (months) Option 1 £1,738,000 £5,214,000 £5,214,000 1 3 Option 2 £666,667 £6,000,000 £6,000,000 1 9 Option 3 (best) £4,000,000 £8,000,000 £4,000,000 2 2 The opportunities with the highest cost of delay \u0026amp; CD3 are the ones worth exploring further. For these opportunities, you want to start validating some of the assumptions you’ve made. Here are some techniques you might want to use to validate assumptions:\nExpert opinion. Sharing your assumptions with others in your organisation to get their opinion Talking to users. Ask them what they think Test with users. Test the current solution and your prototype with users. Record how long it takes for users to complete the task (and whether they complete it at all) Analysing the data. Do you have access to analytics tools or management information that can help? If not, can you start collecting data that will help give you more certainty? User researchers and performance analysts will be able to help you with all of the above. If you have any of those in your organisation, ask for their assistance.\nDuring Beta Once real users are using the service, the team can start to use cost of delay and CD3 at a more granular level. Smaller features which take weeks or months to develop can be considered alongside larger features or new products. This enables the team to stay focussed on the opportunities that deliver the best value for money – whether that involves making small improvements to an existing product or moving into a new problem space.\nThere is a natural bias towards smaller features in CD3. This is a good thing – it encourages the team to break work done into smaller units which increases delivery flow and reduce risk. At the programme level Cost of delay informs decisions about where to focus investment through giving us information on the value of queues. In the table below, Team A has a backlog with a relatively high number of high cost of delay opportunities. The cost of delaying that team is higher. This indicates Team A should be prioritised when people assignment / resourcing decisions are being made. Increasing investment in the problem space that Team A are focussing on may also be a good option.\nTeam A Team B Opportunity Cost of delay Opportunity Cost of delay Option 1 £3,000,000 Option 1 £1,000,000 Option 2 £2,500,000 Option 2 £800,000 Option 3 £1,500,000 Option 3 £750,000 To effectively use cost of delay across multiple teams, there needs to be an effort to standardise how it is calculated. The assignment of monetary values to benefits should be done consistently. For example, time saving for users is a big source of benefits for most Government projects. They should all use a consistent value of citizen time.\nHow to calculate cost of delay Calculating value When calculating value, I like to consider what benefit the opportunity could deliver once it’s live.\nFor government projects, key benefits that we deliver are:\nStaff cost reduction (internal) Non staff cost reduction (internal) Cost avoidance (internal) Saving time for citizens (external) Saving citizens from paying a fee (external) Saving time for professional users (external) Saving professional users from paying a fee (external) Waiting time reductions (external) Opening data (external) Fraud reduction (external) In the private sector and some parts of the public sector, you will also want to consider revenue.\nTo illustrate how to calculate value, let’s take the example of a feature to enable online signatures for an ID Card registration service with 1 million transactions per year. Without this feature, users complete the form online then have to print if off, sign and send it in. Let’s imagine a future state when this feature is live: with this feature they will be able to sign their application digitally in the web browser. We might assume:\n90% of users use the digital service over other channels All digital service users save 10 minutes per transaction (from not having to print it off and scan it in) All digital users save 60 pence (from not having to post it in) Staff save 5 minutes per transaction (from not having to manually check the signatures) Digital service user time is valued at £7.83 per hour (minimum wage. Your organisation may have other standards for this value) Staff time is valued at £20 per hour Benefit type Value Assumptions Total £3.224m External £1.174m 1,000,000 transactions * 90% take-up * 10 minutes * £7.83 p/h citizen rate External £0.54m 1,000,000 transactions * 90% take-up * 60p postage saving Internal £1.5m 1,000,000 transactions * 90% take-up * 5 minutes * £20 p/h staff rate The potential value of doing this work is £3,224k per year. This is of course a simplification – but it helps us understand the ‘size of the prize’ from pursuing this opportunity relative to other opportunities we could pursue.\nValue of enablers Some pieces of work we do not do because they deliver value themselves, but because they enable the delivery of future value. This is what I call an enabler. The best way I’ve found to assign benefit to an enabler is to attribute a fair portion of the future value that it unlocks. Where an enabling piece of work takes 3 months and it enables a valuable new feature that 9 months, it’s fair to attribute 25% of the end benefit of the new feature to the enabler, as 25% of the time it takes for the team to deliver that features comes from the work required to do the enabler. Back to the example of digital signatures, let’s say that one of the benefits of this feature is that it could enable future work to automate application processing.\nDuration Internal benefit External benefit Enables Digital Signatures 3 £1,500,000 £1,714,000 £2,000,000 Automated Application Processing 9 £6,000,000 Value of information When developing Government services, much of the work we do is useful because it helps us generate more information. Information is useful because it reduces the likelihood of us making bad decisions. To factor in the value of information, consider how much you would be willing to pay for that information if it were available on the market, or how much it might cost you if you made an imperfect decision. Benefit that is very hard to put a £ value on If something is intangible and hard to put a figure on, it’s still worth trying. Just consider what the benefit is, and how much it’s worth to your organisation, and write down the assumption. That enables it to be compared against others opportunities. Recording the assumption also makes it clear to others what non monetary benefits are factoring in to decisions, and an idea of what weight they’ve been given. I record these values as non-monetary, so that they aren’t confused with more demonstrable benefits.\nCalculating urgency I don’t use £ values to estimate urgency. Instead, value is multiplied by urgency.\nUrgency = 1 if value \u0026amp; cost won’t be affected by doing this opportunity later.\nUrgency = 2 if delaying reduces potential value\nFor any business, urgency is usually driven by competition – the fear that if an opportunity isn’t seized quickly others will get there first. Government isn’t driven by this same sense of urgency. The key factors that will make Government opportunities more urgent is whether there’s a deadline attached to it, and the consequences of not hitting that deadline. The best example of urgency in Government in the UK at the moment is Brexit – anything that’s needed for when the UK comes crashing out of the Union is going to be high priority\nBringing it all together Here is a google docs copy of the template I’ve been using to visualise assumptions from teams and calculate/compare the cost of delay and CD3. It consists of three tabs:\nglobal variables \u0026 assumptions benefits assumptions for each opportunity (use one per opportunity) summary table comparing all opportunities Using this information wisely Remember, this is a model. It is a simplification of reality that enables more effective decision making. Accuracy is reduced because factors such as take-up and operations cost are ignored. But it’s as accurate as it needs to be to enable good prioritisation decisions, and effective communication of those decisions.\nMore information For anyone interested in learning more about cost of delay and CD3 I recommend Black Swan Farming. Much of what I discuss in this blog post is more comprehensively explained by Joshua Arnold – the site’s author. A big thank you to Joshua for answering many of my questions on this topic!\nDo get in touch if you have any feedback on the techniques discussed in this post. I am still fairly new to cost of delay and keen to improve my practice.\n","permalink":"https://alaniswright.com/blog/how-government-digital-teams-can-use-cost-of-delay-to-prioritize-work/","summary":"\u003cp\u003eOver the past year I’ve been learning a lot about cost of delay.  In this blog post I explain what I’ve learned so far, and how it can be used by teams to prioritise work.  My focus is on teams that are following the UK Government Digital Service Standard, but it can be of use to any team.\u003c/p\u003e","title":"How Government digital teams can use Cost of Delay to prioritize work"},{"content":" In most digital teams the vast majority of budgets are spent on people. People are our biggest assets. Almost all of our value is produced by them. Small changes in our ability to reduce the number of resignations and motivate them to work have an exponential impact on productivity. In the same way that user centred design has enabled organisations to create better digital services, relating to staff as people enables us to better understand what motivates them and create an environment where they can produce their best work. It takes time and effort, but the impact on productivity makes it more than worth it.\nHowever, when making plans for the future, the industry talks about resources rather than people. I feel just a little bit pedantic being that person who calls people out on their use of a word. But if it is true that the words we use shape the way that we think, it’s important that we use the right ones.\nWe need to stop talking about people as resources. People are not resources. We are social animals who get along with some better than others, and usually storm before we can perform. We have hopes, dreams and ambitions that are constantly evolving. We are intelligent, opinionated and are more intrinsically motivated when we have autonomy. We work best when we find a sense of purpose in our work. We are motivated by managers who take time to understand who we are and think of us as more than cogs in a machine.\nWhen we plan with resources, it’s comparatively easy for an intelligent designer to predict how much of each resource we will need, and how they combine to produce a valuable outcome. Workers in a low skilled repetitive industry can be relatively interchangeable. For knowledge industries like digital, value is produced by tight knit teams of highly skilled people who communicate extensively while doing non routine work. You can’t just swap one developer for another and always expect the team to carry on performing as they were before. And you can’t assume that adding new people to a team will speed up delivery. Trying to make ‘resource plans’ without having a connection and intimate knowledge of the individuals and teams concerned increases the risk of bad decisions being made.\nSo when we’re planning the work of digital teams, let’s reserve the word resources for desks, chairs and monitors and make plans with people instead.\nAlso, check out Emily Webber’s awesome ‘Should you call people resources?‘ blog post. She’s made some stickers!\n","permalink":"https://alaniswright.com/blog/people-over-resources/","summary":"\u003cp dir=\"ltr\"\u003e\n  In most digital teams the vast majority of budgets are spent on people.  People are our biggest assets. Almost all of our value is produced by them. Small changes in our ability to reduce the number of resignations and motivate them to work have an exponential impact on productivity.","title":"People over resources"},{"content":"Firebreaks on GOV.UK are similar to Google’s 20% time or Spotify’s hack week. For 1 week every 3 months, teams disband and everyone is given a chance to have some self-directed time to improve GOV.UK. We’ve had 3 firebreaks now: June, September and December 2017. This blog post explores why we do them, how they work and the benefits they bring.\nWhy we do firebreaks Our teams work using iterative agile methodologies, and aim to deliver value to users incrementally and often. This way of working is intense. Nobody can sprint all of the time. People need some time to pause and recharge.\nFirebreaks are not just for taking a break. They’re also an excellent opportunity for staff to pursue other work that’s of interest to them and of value to the organisation. This includes things such as prototyping innovative new features, fixing technical debt and trying out new technologies. There are a lot of talented people working in government, and we believe that giving them this creative freedom will generate value for us and make them happier and more productive.\nFirebreaks also serve as a natural breakpoint as teams wind down their old missions and prepare to start their new ones. This gives us a bit of a buffer in which to resolve any niggling team formation issues that remain for the next quarter, and do other disruptive chores, such as seating reorganisations.\nHow we do it Keeping the lights on\nSadly, not everyone can participate in every firebreak. Urgent support requests must be dealt with promptly. We have a rota to make sure that if someone missed a firebreak they will be free to participate in others. And we notify publishers across government ahead of time that only urgent and high-priority work will be done in firebreak week. Everyone else can participate in firebreak.\nSet the ground rules\nAll firebreak work should meet the definitions of ‘done’, which means it should be:\nresponsibly built (doesn’t add to support or tech debt burden) complete (no extra work required outside of firebreak) of value (leadership reserve the right to reject proposals, though this rarely happens) Gather proposals\nAnyone can propose a firebreak activity. They need to write it up in a specific format, explaining: who you are, what you’re pitching, why it’s worth doing and what skills you need. We put all proposals on Trello so that everyone can view them.\nPitching proposals\nOn Monday morning of firebreak week, everyone who wants to form a team for firebreak does a 2-minute pitch to others on their proposal. At the end of the session, people select what they want to work on and kick off their teams or solo projects.\nDoing the work\nTo help spot dependencies and avoid people stepping on each other’s toes, we do a remote firebreak stand-up every day over Slack. For proposals that involve development work, stuff has to be deployed to production by Thursday. We do this so we have time to correct any errors that might be caused by a deployment, a lead developer oversees the process.\nShow and tell\nOn the Friday afternoon, everyone gets back together for a show and tell to showcase all the progress that has been made during the week.\nWe’ve achieved some amazing things from our firebreaks Here’s a non-exhaustive list of some of the things that have been achieved during firebreaks:\nExperiments and prototypes\ncrowdsourcing for user research automatic readability checking of content within publishing applications Value delivered to users\nenabled admins to track missing links in content pages improved publishing process for service assessment reports Technical debt paid down\nstyling issues fixed in legacy publishing applications made the use of schemas more consistent in our publishing platform Tools improved\nGOV.UK chrome extension improved to help teams identify design elements on pages Slack messages improved to assist developers in coordinating deployments Training and guidance improved\ninduction guidance for new joiners learning materials for junior developers Some of the things trialled in firebreaks have been added on to our roadmap, and will be further developed by product teams throughout 2018. We’ve got no plans to stop doing firebreaks anytime soon, so we’re hoping for lots more valuable work to be delivered in the future.\nThis blog post was originally published on Inside GOV.UK\n","permalink":"https://alaniswright.com/blog/firebreaks-on-gov-uk/","summary":"\u003cp\u003eFirebreaks on GOV.UK are similar to Google’s \u003ca href=\"http://uk.businessinsider.com/google-20-percent-time-policy-2015-4\"\u003e20% time\u003c/a\u003e or Spotify’s \u003ca href=\"https://labs.spotify.com/2013/02/15/organizing-a-hack-week/\"\u003ehack week\u003c/a\u003e. For 1 week every 3 months, teams disband and everyone is given a chance to have some self-directed time to improve GOV.UK. We’ve had 3 firebreaks now: June, September and December 2017. This blog post explores why we do them, how they work and the benefits they bring.\u003c/p\u003e","title":"Firebreaks on GOV.UK"},{"content":" GOV.UK is relied on by millions of people every day to access vital services and information. Material published on GOV.UK can move financial markets. GOV.UK is a vital part of our national infrastructure. But GOV.UK differs from most other pieces of national infrastructure in one respect: we built it and we run it using agile. GOV.UK has been live for more than 5 years and we’re constantly iterating and improving it based on feedback. GOV.UK has always been – and will continue to be – agile at scale. But being agile doesn’t mean simply installing a methodology and then religiously sticking to that methodology. It means adapting what we do based on what we’ve learned. And this includes adapting our ways of working. A little while ago we learned that we had a few challenges with GOV.UK delivery. So we had to adapt our approach. Here’s what we did and what we learned. Moving fast and accruing debt We built GOV.UK very quickly. It launched in 2012 and just over a year later it was hosting all the content for 24 ministerial departments and 330 organisations. By 2015, it had replaced the sites of 1,882 government organisations. But doing all this had come at a cost. We had accrued a lot of technical debt by building things quickly that might cause challenges later down the line. And the number of people working on the programme had fluctuated, meaning that there wasn’t much stability. As the programme matured, it was time to step back and review our ways of working. By the beginning of last year, we noticed 4 problems that were affecting delivery: as deadlines could be flexible, sometimes work wasn’t stopping greater clarity was required on the most important problems research effort wasn’t always reflected in delivery we had too many potential single points of failure So we put in place a new way of working to deal with these. A new way of delivering We put in place 4 new principles to help improve delivery on GOV.UK: 1. Spend only 3 months per mission We wouldn’t commit to any mission – or piece of work – that lasted longer than 3 months. That was because every 3 months we wanted a genuine re-evaluation point where we could say: “Do we definitely want or need this work to continue? What is the compelling proposition for another 3 months on it?”. We kept the time period short because we wanted to build in the flexibility so that we could change direction, if we needed to. Time was fixed and scope could be trimmed. 2. Measure stuff with numbers We would use metrics to see how we’re doing. But proper metrics, not fluffy key results. Teams were tasked with defining how they would undeniably be able to show that their 3 months of time had been a good investment. 3. Have firebreaks Between each 3-month mission we would have a 1-week firebreak. This would be a chance for teams to work on anything they wanted. Doing this would remove any possible build-up of pressure, make more space for learning, foster creativity and allow time for team reconfiguring. 4. Prioritise sustainable building Sustainable building\u0026nbsp;would be a must – we need to have less problematic technical debt. You can read more in\u0026nbsp;this blog post about our 2017-2018 roadmap. Putting this into practice This new way of working would be quite a big change for the people working on GOV.UK. It would mean that they could be moving across missions and teams every 3 months. So we took a number of steps to introduce it carefully. Firstly, we mapped our planned missions against the headcount, to make sure we had the right number of people and the right skills. Then we sent out a survey to all staff asking them what teams they would be interested in working on or had any relevant experience in. \u0026nbsp; Before we announced the teams, we also ran drop-in sessions for people to come and find our more about the new model. And we met lots of people individually to talk about their preferences and development opportunities. We’ve been running this model on GOV.UK for just over a year now. And it’s also being used by other parts of GDS. What we’ve learned This model can be successful When we first started working in this way, most teams faced challenges with incremental delivery, delivery at pace, sustainable building, doing things with data and responsiveness to change. Now we are starting to excel in these areas. We achieved this through extensive training for teams, strong messaging and support from programme leadership, moving seniors into broader roles where they can oversee the work of several teams, and lots of sharing of best practice between teams. Large programmes can be made more manageable With 168 people across 24 teams, GOV.UK was a relatively large programme. \u0026nbsp;As a management team, we found it difficult to effectively manage at this scale. To counteract this, we’ve split our work into a handful of objectives, with each objective containing 3-5 related missions and about 40 people. Most people are assigned to teams, but some people are assigned to specific objectives so that they can help out on each mission as needed. \u0026nbsp; This move towards working in smaller groups rather than one big group helped teams to become better at self-organising and more adaptable to change. Having senior team members leading objectives gave them the space and context to help out with long-term thinking and coach best practice to more teams. Stopping things is hard (but it gets easier) We are all very passionate about our work, and it\u0026#8217;s hard to stop doing something when it looks like there is more to do. But it’s best to do less and do it well rather than to be too ambitious and have no slack for the unexpected. When we did decide to pause work on missions, there was an initial and negative emotional reaction from team members. However, in the longer term, the reduction in work in progress was a relief as it allowed us to do what we did to a higher level of quality. We need to provide clear direction to teams It took us some time to get the balance right between giving teams clear direction and the autonomy to solve problems. Over the year, we’ve learnt that good missions need 3 things: a clearly defined problem for the team to solve clearly articulated measures of success and definitions of \u0026#8216;done\u0026#8217; a steer on the expected scope/direction (if leadership have a view on this) The team should be free to challenge any of the above, but it is critical to have a shared understanding of the purpose of the mission from the very beginning. Varying mission lengths can avoid dysfunction Initially, we decided missions should be 3 months long. But some pieces of work need a guarantee of longer than 3 months – otherwise it could create dysfunction in the way the team members prioritise work. Now we are experimenting with missions of variable lengths. \u0026nbsp;Smaller missions or exploratory work could be 6 weeks in length, and more clearly defined work could be 12, 18 or 24 weeks in length. The model needs to work for part-time team members In a perfect world, team members are dedicated 100% to their team. However, this is not always realistic and some roles have to be shared. \u0026nbsp; We have found a number of ways to help part-time team members: reduce the need for people to be split across multiple teams by reducing the number of teams group part-time team members by objectives and allow them to work with the senior delivery manager on their objective to decide how they should allocate their time between the missions give part-time team members a primary team, and allow them to consult with other teams as required It’s important to measure from the start Our measures of programme performance became much better as we progressed through the year. We also started running a regular survey at the end of the first quarter to give us quantitative data on people’s satisfaction and productivity. However, if we could do this again, we would invest heavily in establishing and baselining programme performance measures right at the beginning, and implement the change once effective measurements were in place. Staying agile This new way of working on GOV.UK affirms our commitment to agile. It means we can move quickly and respond to learnings or changing circumstances, and reduce the cost of any changes. We\u0026#8217;re making better use of taxpayers\u0026#8217; money by more frequently delivering improvements that will make GOV.UK better and improve users\u0026#8217; lives. This blog post was originally published on Inside GOV.UK. Co-authors include Nick Tait and Jen Allum. ","permalink":"https://alaniswright.com/blog/gov-uk-a-journey-in-scaling-agile/","summary":"\u003cp class=\"wp-block-paragraph\"\u003e\n  GOV.UK is relied on by millions of people every day to access vital services and information. Material published on GOV.UK can move financial markets. GOV.UK is a vital part of our national infrastructure.\n\u003c/p\u003e\n\u003cp class=\"wp-block-paragraph\"\u003e\n  But GOV.UK differs from most other pieces of national infrastructure in one respect: we built it and we run it using agile. GOV.UK has been live for more than 5 years and we’re constantly iterating and improving it based on feedback. GOV.UK has always been – and will continue to be – agile at scale.\n\u003c/p\u003e","title":"GOV.UK: a journey in scaling agile"},{"content":"In this post, I’m going to explain my system for keeping myself organised and productive. This system has been working well for me for the past two years, and I have helped a number of people to set it up for themselves. For my fellow productivity geeks, here’s a spoiler alert: it involves Getting Things Done, Personal Kanban, Inbox Zero and Trello. The target audience for this blog post is newbies, so this should be a good place for you to start if you don’t know what any of those things are.\nNote that this system is not for everyone, and this blog post is not meant to be a grand universal theory of productivity. It’s just a description of what works well for me, my thoughts on why it works, and some tips on how to get started with something similar yourself. And it is not something that I’ve invented – most of it is based on practices that I have read about elsewhere which I’ve referenced throughout.\nBefore I dive into the detail, I want to start with a primer on some of the key principles on which the system is based.\nPrinciples Let’s start with a definition. Productivity is about producing more value with the same amount of effort. See the focus on “value”. What you produce must actually be useful and meet some sort of long term goal. Also see the focus on “the same amount of effort”. It’s not about working longer or harder – it’s about working smarter.\n1: Look after your health\nThe most important factor that affects productivity is health. Unhealthy people are not productive. Stress, anxiety, sleep deprivation, lack of exercise and an unhealthy diet all have a big impact on your ability to do anything well. This is one of the big reasons why people who work less hours are often more productive: all that rest makes for a healthier person, so that when they do work, they work better.\n2: Start with the end in mind, but keep long term plans high level\nTo be genuinely productive, you need to have some long term goals. Without these, you cannot be confident that your day to day activities are really worth doing. However, detailed long term plans are wasteful as our circumstances and priorities are constantly changing.\n3: Do something that motivates you\nDaniel Pink wrote an excellent book in which he argued that autonomy, mastery and purpose are the three main sources of motivation. It takes less willpower (or effort) for a motivated person to start or continue a task, so a motivated person has a clear advantage. Looking at the big picture, there isn’t much point in being productive if you can’t find a purpose in what it is you are doing.\nSteve Jobbs said “The only way to do great work is to love what you do. If you haven’t found it yet, keep looking. As with all matters of the heart, you’ll know when you find it.” How we work is also important to motivation too. We enjoy our work more when we have autonomy (the opportunity to solve the problem in our own way) and mastery (the opportunity to do the job to a high standard).\n4: Habits reduce the energy required to do things\nDoing things takes energy (sometimes not doing things takes energy too)! Energy is finite, and you need to use it wisely. Habits reduce the energy required to do a repeatable task. They are your brain’s autopilot. Once you learn how to do something on autopilot, you don’t have to put as much energy into doing it. This leaves you more energy to focus on doing other things.\nBrushing your teeth is an excellent example of a habit – most people do it at the same time every day and it doesn’t take any effort to start doing or to do. You just do it in your sleep twice a day without thinking. Take advantage of habits to become more productive. Identify things you should do every day or week, put the effort in to make them a habit and then reap the rewards when that thing no longer takes much effort to do.\n5: 80% of value can be achieved with 20% of effort.\nThe idea 80% of the value can be achieved with 20% of the effort is known to economists as the pareto principle. In some situations the split is more like 90/10 or 70/30, but the point is the same. This principle is key to agile development, where the most valuable work is prioritised and delivered first. Once this is done priorities are re-evaluated before work begins on the next most valuable work, and on and on. Detailed long term plans are avoided in favour of delivering the most valuable work in small batches.\nWe should apply this principle to our personal productivity. We must become comfortable with not doing everything on our to-do-lists. Do the most valuable tasks first every day and move on to the less valuable tasks another time.\n6: Multitasking is not efficient. Do one thing at a time and do it well\n98% of humans cannot effectively multitask, and do not realise that constantly switching between tasks massively reduces their ability to focus and be productive. When most people multitask, they are rapidly switching between tasks. This involves lots of context switching, which is inefficient. Brain capacity is taken up by remembering the different contexts and navigating between them rather than on solving the problem at hand. So instead of multitasking, focus on doing one thing at a time and do it well.\n7: We are at our most productive when we are focused and in a state of flow\nBeing in a state of flow is when you’re fully immersed in a specific task with a seemingly inexhaustible amounts of focus. You are ‘in the zone’. Five hours may zip by, and you hardly even notice. This state of flow is when we are at our most productive.\nHow do you get into a state of flow? Choose work you love. Choose an important task. Make sure it’s challenging, but not impossible. Find some quiet time. Clear away distractions. Focus. Enjoy yourself.\nLet’s recap:\nLook after your health Find meaning in what you do Have long term goals in mind Use habits to get more done with minimum effort Prioritise your work Do the most important things first Do them one at a time Maximise the time you spend in a state of flow These are the principles on which my personal productivity system are based. Now, let’s move on to some of the practices.\nGetting Things Done GTD (Getting Things Done) is a system for collecting, processing, organising, reviewing and doing your tasks and projects. It was created by David Allen.\nThe problem Allen noted that our minds are overrun with thoughts: groceries I need to buy, a voicemail I need to return, an interview I need to prepare for, a blog post I need to write (and the list goes on). A constant stream of thoughts like these stops us from focusing and makes us unproductive, uncreative and stressed.\nThe solution Each time one of these thoughts pop into your head put it into a task management system. Get into the habit of spending a little bit of time each day keeping this system organised. Once you know you can rely on the system to be accurate, you will be able to spend less time worrying that you have forgotten something or should be doing something else and more time actually doing the things that are of high priority.\nThe task management system he proposed consists of different lists where you put tasks or ideas. Below is a simplified version of the getting things done workflow that I use:\nStep 1. Collect New tasks and ideas can come from anywhere: conversations, meetings, emails, messages or divine inspiration. Wherever they come from, they all end up in a list which I call ‘inbox’. It is important to collect everything into one place so that it can be relied upon as a canonical source of all tasks that need doing. This gives me confidence that important things aren’t being forgotten and allows me to focus.\nStep 2. Process \u0026amp; organise I frequently review the inbox and ask myself the following questions:\nIs it actionable? If not, and if it’s something I might need to refer back to in the future, then I keep a note of it. Evernote is what I use for this. If it is actionable then I ask myself:\nWill it take longer than two minutes? If not, the time it takes to process it is too high relative to the cost of doing it, so just do it. Otherwise you should put it in one of your other lists.\nIf it is actionable and takes longer than two minutes to do, it should end up in one of these lists:\nInbox This is the list where you collect all your new ideas and tasks. \u0026nbsp;It should be reviewed at least once per day. Priority These are things that must be done today. \u0026nbsp;Don’t do work from any of the other lists until this one is empty. Backlog These are things you need to do, but not necessarily today. \u0026nbsp;On busy days, you won’t get a chance to look at this list. Someday Things you might do on a quiet day. Mostly contains things you haven’t accepted that you’ll never get round to. Periodically cleanse this list of those things. Archive For things you won’t do or have done. Waiting for For tasks where you are dependent on someone else. For example, if you’re waiting for someone to check your blog post before you publish, that task goes here. Scheduled For tasks that need to be done on a specific day. For example, you may want to notify yourself when it’s time to renew a contract or fill in a timesheet. Projects Projects take more than one task to complete (eg. move house, learn to code, buy christmas presents, etc). \u0026nbsp;For each project, identify the 1-3 tasks you need to do next and make sure these are included in one of your other lists. \u0026nbsp;When these are done, identify the next most important/urgent tasks. Repeat this process until the project is finished. This keeps you progressing towards completing the project, without clogging up the system with lots of small tasks that all relate to one project. Other lists Feel free to create new lists as and when the need arises. Examples include groceries, books to read or things to learn. Step 3. Review and do Work through tasks in priority order. Start with things that need to be done today. Do them in priority order. Move onto the other lists only once today’s tasks have been dealt with.\nDon’t spend all day moving tasks between lists. Instead, hold daily reviews of 5-10 minutes at least once per day to keep things organised. Focus on inbox, priority and waiting for – the other lists don’t need to be reviewed every day.\nWeekly review. Review your main lists. Move tasks around if their priority has changed. Archive anything that’s no longer relevant. Check in on all your projects and make sure that your next actions are properly prioritised.\nPersonal Kanban (with Trello) Kanban is a process used to manage the workflow of teams. The are two steps involved in creating your own Personal Kanban:\nStep 1. Visualise your work Do this by putting all your lists side by side, and include two new lists: ‘In Progress’ and ‘Done’.\nI keep my most frequently used lists on the left: Inbox, Priority, In Progress, Waiting For and Done. This visualises how tasks move from inbox, to being prioritised to being done. On the right I keep the lists I use less often: ‘Backlog’, ‘Scheduled’, ‘Projects’ and ‘Someday’.\nTrello is the perfect tool for this. It is a free digital product that allows you to have multiple lists on one screen, and multiple tasks in each list. It is easy to move tasks between lists or to change the order of lists.\nStep 2. Limit your work in progress We know that humans achieve more when we focus. So set limits on the number of tasks you prioritise and do. I set a limit of five tasks in ‘priority’ and one task in ‘in progress’.\nPlanning to do more than five tasks today? A long to do list is intimidating. Break it down into smaller chunks that are more achievable. Pick the five most important ones and move the others off your list. Once these are done, see if you have time to do the others. If not, reschedule. If they’re important enough you’ll get to them eventually.\nWorking on more than one task right now? Remember that 98% of humans cannot effectively multitask. Do one thing at a time, finish it, then do the next thing.\nWriting good tasks It is important that tasks are small enough to complete in a few hours. Breaking work down into bitesized chunks makes it easier to avoid procrastination. Completing multiple small tasks gives me more of a sense of achievement than getting half way through a mammoth task.\nEach task should have a brief title – just enough to tell you what action is required. Any extra information or links can go into the notes. Where a task takes multiple steps to complete you can add checklists to break it down further, or break it down into multiple cards.\nKanban vs To-Do Lists I previously tried using Getting Things Done with Wunderlist, a conventional to-do-list application. I found Trello and Personal Kanban to be superior for two reasons:\nBeing able to see all lists on one screen gives me an immediately available view of my goals, high-priority actions, work in progress, dependencies and achievements. This gives me all the information I need to manage my workflow at a glance. Without work in progress limits, lists can become too cluttered. This makes it hard to focus on the actual priority. Getting set up on Trello Use my trello board template to replicate this system for yourself.\nYou can power up your Trello by using\nLabels chrome extension. It can be useful to categorise work by type or context. For example, you may want to label all tasks by the project they relate to. Trello’s labels provide an excellent way of doing this, and can be filtered once applied. This extension included the label text inside your label – one piece of functionality I really believe that Trello should have out of the box. Butlerbot. This excellent tool allows you to make your Trello more intelligent. I’m using it to move tasks from ‘scheduled’ to ‘today’ on the day they need to be done, and add a ‘weekly review’ task into my to do list every week, but it’s capable of much more advanced logic. WIP chrome extension. Allows you to set limits to the number of tasks that can appear in each list. When the limit is reached the list turns yellow. When it is exceeded, it turns red. The colour indicators nudge me toward respecting the limit, but don’t prevent me from exceeding it if the need arises. Adding new cards quickly I have a shortcut on my phone and an extension on my web browser that enables me to add a task to my inbox in 2 clicks. This enables me to quickly add ideas and tasks which I sort through at the beginning and end of each day.\nRecommendations Don’t write detailed trello cards for yourself. When writing tasks for teams, detailed descriptions are needed so that others can understand the context. This isn’t necessary if you are the only one using it.\nSeparate work and play. I keep separate accounts for my personal and professional life. Why? When I’m at home, I don’t want to have work tasks ruining my zen. So if I remember something about work when at home, it ends up on a work list that I forget about until I’m in the office.\nDon’t be too zealous about work in progress limits. Sometimes, something super-urgent comes up and you may need to break your work in progress limits. It’s not the end of the world if this happens. They are there to nudge you in the right direction, and it’s okay to bend the rules occasionally.\nDon’t record obvious things. If there’s something you do every day or that’s in your calendar, there’s no need to keep it in your to-do list as well. For example, if you need to review the work of a colleague, schedule some time to talk to them, add it into your calendar and assume that the task will be completed during the meeting. Removing the obvious things allows you to focus on what matters.\nConsider using more than one board. The web page where all my lists live is called a Trello Board. It’s important to keep all the main lists on one board so that you can see them all at a glance. But if like me you like to keep lots of extra lists, it may be worth keeping this information in separate trello boards. For example, I have a Trello board of books to read. Every time someone gives me a book recommendation it ends up on this board, and when i need something new to read this is the first place I look. I also have separate boards for tv, films, travelling, learning and shopping.\nInbox Zero By applying the principles of Getting Things Done to my inbox, I can be confident that:\nI haven’t missed anything I’m working on things in the right order This is the point of inbox zero. Taking 5-10 minutes at the start, middle and end of each day to process and organise everything in my inbox means that the rest of my working day is spent focusing on the right things. I often receive hundreds of emails a day, and this system works well for me.\nHow to achieve inbox zero (and keep it there) Have thousands of unread emails in your inbox? This might take a few hours…\nSet up a folder structure in your email that matches your getting things done lists. Gmail organises folders alphabetically, so I use numbers and underscores in my naming convention to ensure they appear in the correct order.\nMove all your emails to your new folder structure. This might take many hours at first, but once it’s done it’ll just take a little bit of time every day.\nUnsubscribe from things you don’t need to receive. It’ll mean you get less emails in the future and make email management easier.\nSet up filters to get certain messages to skip your inbox. Some messages can be auto-processed. For example, every fortnight I work on the product triage rota. All emails that relate to this skip my inbox and go straight to a folder, which I only pay attention to on the days that I’m on the rota.\nUse filters to automatically apply labels. Automatically label incoming emails to make them easier to find For example, any email containing the words ‘receipt’, ‘invoice’, ‘payment’ or ‘ticket’ get the ‘receipts’ label applied.\nAdd a reference folder. One extra folder I recommend is reference. Move an email here if it doesn’t need an action, but you know you will need to search for it again soon (eg. important email from the boss or meeting minutes). This is a quick and clean way of bookmarking important emails for future use.\nDon’t do these things Create lots of extra email folders. A researcher called Steve Whittaker installed logging software on the computers of several hundred IBM workers (with their permission), and tracked around 85,000 attempts to find email. They found that people who clicked through folders found emails more than 50% slower those who used other methods such as search, and had just as high a success rate. Taking into account the time needed to create and maintain an elaborate folder structure, those who rely on search along would be even faster still. This indicates that if you want to get quicker with email, spend less time moving things between folders and more time using search. It’s well worth taking the time to learn how to use search operators so that you can search for emails even more effectively.\nManually sync your email and Trello. Roughly half of my tasks come from email. It would take too long for me to keep email and trello in sync. Instead, I only add an email to Trello if it requires an action beyond responding to the mail.\nLong term focus Getting Things Done, Personal Kanban and Inbox Zero will keep you organised. But being productive isn’t just about producing more – it’s about producing more value. What is valuable to you? That’s worth taking some time to think about.\nA personal mission statement is an excellent tool which helps you to answer this question. It involves articulating the type of person you want to be, and what it is you want to achieve in your life. From there, you can identify goals which help you to achieve your mission, and day to day activities that allow you to achieve those goals.\nRegularly review your mission and goals I have set up a long term planning board which includes my personal mission, future goals and completed goals. Every 3 months, I complete the following activities:\nreview my personal mission, and make any changes or improvements that are needed review the goals I set 3 months ago. If achieved, i move them into the completed goals list. identify goals I’d like to pursue next that take me nearer towards achieving my mission. For example, my current goals are to set up my company, find my first contract, move house, learn to draw and meditate daily. These are all listed in the projects list on my planning board. This helps me keep my mission and goals front of mind when i’m planning my daily work. Keep long term tasks off the personal kanban The long term planning board helps keep me focussed on goals which matter to me. It’s also a useful place to store any tasks on your planning board that aren’t going to be done anytime in the next month or so. I have a list of future tasks on my planning board where all these things go. I also keep any far away scheduled tasks on here – such as the date for when I need to renew my phone contract. This helps to keep the planning board free from clutter.\nRecommended reading Well done on making it to the end!\nIf you’re interested in learning more about personal productivity, I recommend the following books:\nThe 7 Habits of Highly Successful People The Power of Habit Flow Personal Kanban Getting Things Done Drive ","permalink":"https://alaniswright.com/blog/how-i-stay-organised-using-trello-kanban-gtd-and-inbox-zero/","summary":"\u003cp\u003eIn this post, I’m going to explain my system for keeping myself organised and productive.  This system has been working well for me for the past two years, and I have helped a number of people to set it up for themselves.  \u003c/p\u003e","title":"How I stay organised using Trello, Kanban, GTD and Inbox Zero"},{"content":"This post explores how we plan who works on which team on GOV.UK, and how that process has evolved throughout 2017-2018. Background At the beginning of 2017, there were 168 people on GOV.UK split into 24 teams. GOV.UK was one of 6 programmes in GDS’s portfolio. Moves happened constantly and at any time, both between teams on the same programme and between programmes. These were handled on a case by case basis, when a need was identified by the programme.\nIf we couldn’t fill vacancies internally, we would make a business case to recruit externally.\nGetting started The quarterly cadence of our 2017-2018 roadmap enabled us to plan with more flexibility and clearly communicate mission work, which gave people the opportunity to say where they had relevant skills and interests.\nWe started with a draft ‘people plan’, mapping our headcount and skill profile against the missions we planned to run. Doing this each quarter helps us validate that we have enough people to do all the things we want to. The roadmap and team selection process were presented to everyone at an all staff meeting.\nAfterwards, we sent out a survey asking staff what teams they would be interested in working on or had any relevant experience in. Drop in sessions were arranged for people to find out more from the management team. The programme team (the senior leadership team) then reviewed all the respondents’ preferences and comments, often meeting with individuals to discuss their preferences and development opportunities.\nThe people plan was created by the lead delivery manager in collaboration with the programme team, then shared with team leads 2 days early so that issues could be ironed out before the teams were announced. Teams were announced in March, and started working together at the beginning the new financial year in April.\nGOV.UK has run this 4 times now – in March, June, September and December. And we’ve iterated the process each time.\nWhat we learnt and changed How management chooses which person is on which team. There’s lots of factors to take into account when deciding teams. Here are the key factors we consider in rough priority order:\n**Business need. **What capabilities do we need on each team? Are there any individuals who have context from working on a similar problem before? This is our most important consideration. **Team dynamics. **How do the different skill sets on our team complement each other? What can team members learn from each other and the work itself? **Productivity. **Teams take a long time to become high performing, so regularly chopping and changing is bad for productivity. We try to keep high performing teams together. Each quarter roughly 20% of people have changed teams, which feels about right. **Personal preference. **Where we can’t give someone their preference, we always speak to them individually before teams are decided. **Diversity. **We aim to have diverse teams but in previous quarters have not got the balance right. There are limitations to what planning can do, so our recruitment strategy has a part to play too. GDS’s dedication to increasing diversity and creating an inclusive workplace will help. Delegating more team selection decisions With 170 people across 15-20 teams, GOV.UK is a relatively large programme. As a management team we’ve found it difficult to effectively manage at this scale and teams have struggled with having to escalate requests for extra support.\nWe started the year with 6 objectives and 24 teams. Each objective contained 3-5 related missions on which the teams would work. To counteract the issues presented by scaling, we allowed more decisions to be made at the objective level. Most people are assigned to teams, but some people including the senior product manager, senior delivery manager, tech lead and part time team members work across the objective so that they can help out on each mission as needed. We’ve set the expectation that there will need to be some self-organisation within objectives, and that whilst everyone’s main focus is their mission, people may be required to help out elsewhere in their objective from time to time.\nThis change has helped teams to become more adaptable and allowed movement of people within teams on the same objective to become more fluid. In our new empowered objective structure we are finding it much easier to coordinate our work than we were before and we think this is because of group size – it’s easier for people to cooperate in a group of 45 than it was with a group of 170. This matches what we know about human psychology. Evolutionary psychologist Robin Dunbar found that most people can only maintain stable relationships with 150 people. This indicates that work teams should become less effective as they start approaching that number. Organisations like Spotify have come to similar conclusions – Spotify’s tribes (similar to our objectives) rarely exceed 100 people. We believe that allowing an element of self-organisation and fluidity in team allocation will lead to better decisions.\nPart time team members In a perfect world, team members are dedicated 100% to their team. However, we don’t have those types of budgets in government and roles such as design and performance analysis have to be shared between teams. Even if we did have the budget, not all teams require full time people from every discipline.\nWhen we first started the new roadmap with our new teams, many people were split across multiple teams. When assigning people to teams, we didn’t map part time people to teams in a joined up way. One team included team members who were across a total of 6 other teams, which made simple things like scheduling planning sessions almost impossible! We also found that part time team members were swamped with meetings as they tried to attend all their teams’ agile ceremonies. We have found a number of ways to minimise this issue:\nReduce the need for people to be split across multiple teams by reducing the number of teams (quality over quantity) Group part time team members within a single objective (containing 2-4 teams) and allow them to work with the senior delivery manager on their objective to decide how they should allocate their time Give part time team members a primary team, and allow them to consult with other teams as required Dispel the myth that part time members need to attend every meeting. Encourage teams to invite them in for specific pieces of work as and when their skill sets are required. Anxiety around team selection With 15-20 teams operating at any one time, many people felt that they didn’t know enough to make an informed choice about where they would like to work. I received an increasing amount of anxious messages as the survey deadline approached. To combat this, we’ve tried to provide more information about the missions, sharing summaries for each proposed team and being clear about the roles we think each will require.\nHowever, for a programme of our size and complexity, we’ve accepted that it’s unrealistic for everyone to know about everything. So we now encourage people to use the survey to tell us about the type of thing they’d like to work on or the direction in which they’d like to take their career. This allows us to identify good opportunities without them suffering from the paradox of choice. There’s now less pressure on people to make choices, but the option remains for those who want to.\nPausing or stopping work on a mission Several times, we’ve decided to pause or stop work on a problem so that we can focus our effort on a higher priority. We are constantly learning on GOV.UK. Our strategy is evolving and priorities are changing. Becoming more responsive to change was one of the big reasons for moving to our new quarterly roadmap model, and we’ve set the expectation with all teams that their work could end after 3 months.\nSometimes it makes sense to change direction even when the team concerned would rather carry on. Team members can get very disappointed when it’s their workstream that is coming to an end. It can be a big blow to confidence and morale. For those affected by change, it is important for managers to make sure to give them extra attention when teams are selected to ensure that they know they’re valued and that they have a good understanding of the opportunities available for them on GOV.UK or elsewhere in GDS.\nImproving the team selection survey When we first ran the survey we asked people:\nWhat team they’d like to work on (and why). Whether they are interested in a technical or content leadership role on a team (and why). Over the year, the survey has evolved to ask some extra questions relating to:\nOpportunities to work on other programmes. Their view on change. In the longer term we’d like to keep people who are averse to change working on areas of the roadmap that are more stable. Current team and role (to make it easier for the management team to sort through the data). Advantages of our team selection model The programme team are more aware of the preferences and ambitions of our people. Listening to people helps us make better decisions for them and for the programme.\nMore development opportunities. More people are moving within GOV.UK and GDS. This helps us share best practice throughout the organisation and give people opportunities to try new things.\nTeam stability. As most moves happen every 3 months (instead of all year round), teams are protected from interruption for 3 months at a time. Although people can join and leave the organisation at any time and some urgent moves still happen throughout the year, the greater stability helps teams to become more productive.\nDefined breakpoints. You can’t always be sprinting. The breakpoints every 3 months give us the space to take a break and reflect on what we’ve learnt, generate new ideas and have a breather. It also offers a regular opportunity to reform teams to help them become more functional.\nDisadvantages It’s time consuming. Sharing information with teams, running the survey and selecting new teams takes a lot of time. But we’ve got better at it the more we’ve done it (most recently, it took us 6 days to go from announcing the next quarter’s roadmap to having confirmed teams for the next quarter).\nChange can be disruptive. When we first started asking for team preferences in February, it was a revolutionary change for GOV.UK as we’d never done it before and the roadmap was new. Since then, we’ve kept the number of moves relatively low – around 20% of people move every 3 months. It’s important that management teams do not underestimate the cost of change, and avoid chopping and changing unless the benefits of doing so significantly outweigh the costs.\nIt causes anxiety. For many people, change is stressful. Calling out the possibility of their work changing every 3 months makes them anxious. Before change could happen at any time and was unpredictable, and it was not noticed or anticipated as much. Now that we are concentrating the change in short bursts every 3 months people have become more aware of it. As it’s become clear that most teams are given a lot of stability quarter to quarter this has become less of an issue, but it remains one of my biggest concerns around this team selection model.\nConclusion On balance, this model is working well for us on GOV.UK and we plan to continue using and iterating it in 2018. More programmes in GDS are starting to adopt this approach, and lead delivery managers will begin coordinating the team selection process across the organisation.\nThis blog post was originally published on Inside GOV.UK\n","permalink":"https://alaniswright.com/blog/how-we-do-team-selection-on-gov-uk/","summary":"\u003cp\u003eThis post explores how we plan who works on which team on GOV.UK, and how that process has evolved throughout 2017-2018. \u003c/p\u003e","title":"How we do team selection on GOV.UK"},{"content":"Kaizen, Kanban, Kaikaku. We can’t get enough of these Japanese words in agile! Here’s a lesser known one: Kata. Kata is a term used by Mike Rother to describe a set of routines that Toyota use to ingrain a culture of continuous improvement in their organisation. Each routine is practiced and repeated so that it becomes second nature.\nDuring his time with Toyota he identified two Katas:\nThe improvement Kata is a four-step pattern which enables teams to pursue challenging goals with autonomy The coaching Kata is a method of training people in how to use the improvement kata. Together they were designed to make Toyota’s teams better at working independently to solve complex problems.\nIn this blog post, I explore how digital teams can take inspiration from Kata to deliver value to users more quickly.\nImprovement Kata Step 1 of 4 – Understand the Challenge Step 1 of the Improvement Kata is to understand the challenge. The challenge for each team is decided by leadership. It describes the problem(s) the team should focus on solving or the goal they should be aiming for, and gives them a shared purpose. It is a new condition several months in the future that will take the organisation closer to achieving the vision.\nBefore starting work, teams should collectively review their challenge and clarify any ambiguities. If necessary they should challenge the challenge – leaders should be open to discussing changes in strategic direction where the team can demonstrate there are clear benefits in doing so. There must be a shared understanding between leadership and the team regarding how success will be measured and what the definition of done is.\nStep 2 of 4 – Grasp the current condition Before teams can start figuring out how to progress, they need to figure out where they are now – their current condition. This is something that should be done in a short kick-off stage.\nDo it as a team. This first couple of days give everyone the context they need to make a positive contribution.\nTeam charter. As well as understanding the problem area, teams also need to understand each other. Who are they? What are their capabilities? How do they like to work? A team charter session is a great way to start answering these questions.\nLook sideways (and backwards). Most organisations I’ve worked in already know a lot about their users and have ton of historical research. When designing or redesigning services from scratch, the UK Government Service Standard mandates a 4-8 week discovery stage. A long discovery stage often isn’t necessary for improvements to existing products. Instead, a much shorter period of discovering (or grasping the current condition) usually suffices. Teams should:\nResearch historical work done by others Use organisation and industry communication channels to identify others who might have knowledge to share (or be working on a similar problem) Research what has been done in other industries Mapping. Usually it helps to visualise the status quo so everyone can see how things currently work. Processes, systems and user journeys are all good examples of things a team might want to map.\nResearch question sessions are a great way to build a shared understanding about what you know and don’t know about the challenge. This involves identifying what you don’t know, don’t need to know, think you know and know. This part makes the next stage easy – usually some of the first target conditions in a project will be to address some of the uncertainties identified here.\nStep 3 of 4 – Establish the next target condition A key feature of the challenge is that it is only achievable with multiple increments or target conditions. A target condition is an interim goal on the way to the challenge. Unlike the challenge it is set by the team, and describes a future set of circumstances that lie beyond their current knowledge threshold.\nEach target condition should take a few weeks or more to be achieved. There should be more than one target condition on the road to completing any challenge. The only target condition a team needs is the next one. It’s not necessary to have a three-month plan at the end of week one. Instead, teams should focus on minimising their work in progress and focusing on the problem at hand. One step at a time.\nMost teams work in iterations or sprints, so the target condition is often the goal for the iteration. Some example target conditions for a product improvement might include:\nKnow who your users are, their needs and how well they’re currently being met Identify a prototype solution that you are confident best solves the problem Develop an A/B test on the live product to validate the solution with quantitative data from a subset of users Develop the solution into scalable production ready code Target conditions can also be outcome focused. For example, increasing daily active users by 10%. Steps 1 to 3 should be finished within week one By the end of week one, teams should have understood the challenge, grasped the current condition and established their first target condition. From week two onwards they should start iterating towards their first target condition. The sooner they start validating their learning, the better. Step 4 of 4 – Iterate towards the target condition How does a team get from where they are now to achieving a target condition? They science the shit out of it.\nScientific method involves three steps:\n1. Make a hypothesis. This should be the team’s best guess at what change they believe is most likely to allow them to achieve the target condition.\n2. Devise a test to rapidly disprove the hypothesis and make a prediction about the result. 3. Run the test and analyse the result. If the Result ≠ Prediction then revise the hypothesis or make new one If the Result = Prediction then make additional predictions and test them until you are confident enough in the validity of your hypothesis to proceed to the next obstacle Repeat this cycle as many times as you need to until the target condition is met. Fail fast and use scientific method to learn from your mistakes, and you will improve more rapidly. In the words of Ed Catmull at Pixar, “People need to be wrong as fast as they can”. Some tips on how to do this well:\nDon’t take too long to make a hypothesis. Just pick your best guess and get on and do the test already. If you can’t decide, take a vote on it.\nAlways make a prediction. Without a prediction, you risk succumbing to confirmation bias – the human tendency to find the answer we’re looking for regardless of what the data says.\nIncorrect predictions can be a good thing. An incorrect prediction means you have learnt something from the experiment. If more than 50% of your hypothesis are correct then you’re probably wasting time testing things you already know the answer to.\nTry to disprove your hypothesis. If you set out to disprove your hypothesis then they will fail faster. If they don’t fail, you can have greater confidence in their accuracy. Test the highest-priority and riskiest obstacles first.\nRun tests quickly and cheaply. When you are first starting out with a hypothesis, run tests quickly and cheaply. Before designing a high-fidelity prototype and paying for time in a user research lab, do some low-fi sketches and guerrilla test it with colleagues or family. Before building production-ready code, hard code an A/B test to experiment with a subset of users. Gradually invest more time in experiments as you become more confident in your hypothesis.\nConfidence over certainty. ** **The only things that are certain in life are death and taxes. Hypotheses are never proven true – they are just not proven wrong yet. We may observe 100 white swans in a row and conclude that all swans are white, and then a black swan would come along. Pareto efficiency applies to hypothesis validation – 20% of effort will yield 80% of the value. Don’t wait until you think you are certain an improvement will be a success before deploying it to real users. Instead, once you’ve put in that optimum 20% of effort to have 80% confidence that your hypothesis is correct, validate it with an A/B test on a subset of real users. Too often, product teams aim for certainty. It is rarely worth the cost. Get better at taking calculated risks\nTest one hypothesis at a time. If you change lots of variables at once and then performance plummets, you won’t know which was the cause..\nKeep a log of the tests you’ve run and the results. These are useful to refer back to later, and to use a basis for conversations with leadership. What to do when you meet the target condition Retrospect. This is a great opportunity for the team to reflect on how they have been working. Lessons should be learned, used to improve the team’s future performance and shared with others, solving similar problems in the future.\nRevisit the challenge. Ensure there is a shared understanding of what the purpose of the team is. Ensure the next target condition aligns to it. Don’t get lost in a sea of unrelated improvements.\nSet the next target condition. The next step toward achieving the challenge.\nCoaching Kata At Toyota, managers at all levels in the organisation coach individuals and teams to follow the Improvement Kata. They coach their reports by regularly asking five simple questions:\nWhat is the target condition? What is the actual condition now?* What obstacles do you think are preventing you from reaching the target condition, and which one are you addressing now? What is your next experiment? What result do you expect? When can we go and see what we have learned from that experiment? After each experiment, there’s another four questions to ask:\nWhat was your Last Step? What did you Expect? What Actually Happened? What did you Learn? Through regularly asking these questions of teams and of each other, the improvement kata has become second nature to Toyota teams. Coaches also help the team to understand the challenge/current condition, set good target conditions and develop and test hypothesis quickly and cheaply.\nI’ve found that using these questions in 1-to-1s and planning sessions is an excellent way to focus conversation on the obstacles the team needs to overcome in order to improve. Some tips on how to coach teams to achieve a culture of self improvement:\nGet good at asking questions. Don’t tell the team what to do. Ask open and challenging questions which encourage the team to think and help them to figure out the answer for themselves.\nDon’t be afraid to ask a stupid question. If something doesn’t make sense to you but everyone else seems to be going along with it, put your hand up and ask. Be the one to ask the stupid question. And encourage others to do the same. Be wrong as fast as you can. So you can learn quicker.\nEncourage the team to take calculated risks. We will never progress if we don’t take risks. Encourage the team to test out risky ideas by setting up experiments to minimise the cost of failure.\nStop doing things that aren’t adding value. If you think the team is doing something that is wasting time or energy, ask them why they’re doing it. If they don’t have a good reason, ask them why they haven’t stopped doing it yet. Nothing is off limits, and feel free to be agile with agile – I’ve been on teams before where we’ve stopped doing regular standups.\nCreate a sense of urgency. Focus the team on meeting the next target condition and create a sense of urgency around it. If the iteration is two weeks long but you meet the target after a few days, call a new planning meeting and agree a new target condition.\nRecommended reading If you’ve enjoyed this blog post, check out the Mike Rother’s site for guides, videos and courses to help you get started with Kata.\n","permalink":"https://alaniswright.com/blog/using-kata-to-help-teams-deliver-value-faster/","summary":"\u003cp\u003e\u003cspan style=\"font-weight: 400;\"\u003eKaizen, Kanban, Kaikaku.  We can’t get enough of these Japanese words in agile!  Here’s a lesser known one: Kata.   Kata is a term used by \u003c/span\u003e\u003ca href=\"http://www-personal.umich.edu/~mrother/Homepage.html\"\u003e\u003cspan style=\"font-weight: 400;\"\u003eMike Rother\u003c/span\u003e\u003c/a\u003e \u003cspan style=\"font-weight: 400;\"\u003eto describe a set of routines that Toyota use to ingrain a culture of continuous improvement in their organisation.  Each routine is practiced and repeated so that it becomes second nature.\u003c/span\u003e\u003c/p\u003e","title":"Using Kata to help teams deliver value faster"},{"content":"GOV.UK was recently restructured to help us achieve our 2017/18 roadmap. As a delivery manager, I oversaw the formation of 2 new teams under the new roadmap: Content History and Worldwide Publishing. The aim was to build happy, motivated and productive teams with a strong culture of agile user-centred delivery. This blog explains the steps we went through to start them up.\nIt all started with a spreadsheet Before we could start figuring out how we’d work together, we needed to understand the working preferences of each team member. So we started a shared spreadsheet in which everyone added their working pattern, upcoming holidays, seating requirements and a link to their personal profile on the GDS wiki.\nFrom this we identified the best times for all our regular meetings and booked in some time for a team kick-off. Planning, show and tells, and retrospectivesall happen in the same half-day every week, leaving the rest of the week as meeting-free as possible. This matters because people who make things work best when they have long stretches of uninterrupted time to work, rather than lots of small meetings breaking up their day.\nSetting up the team space Most people in GOV.UK hot-desk, but teams have fixed locations, with space to visualise our progress on wall space, whiteboards and windows. Meeting rooms are in short supply and people often work from home. So we set up a TV and webcam at the end of our desks so that we can use our shared space for team meetings.\nTeams are encouraged to personalise their space to build a shared identity, give the office some character and make it a fun environment to work in.\nWe also have to set up virtual spaces so we can work effectively online. For us this meant:\nGoogle drive folder for all team sheets and documents Google group for team emails and event invites Slack channel for instant messaging Trello boards to visualise and manage our workflow Wiki page to provide an overview of our team’s work to anyone on GOV.UK Team charter The first thing we did in our kick-off meeting was create a team charter to document our collectively agreed team values and working practices. Chartering is a great way for team members to better understand each other’s preferences and lay the foundations for a strong team culture.\nTo create our charter I posed the question: “This is an awesome team to work on because…” and gave everyone 5 minutes to write their ideas on post-its. Each person took turns to explain what they had written and add their post-its to the wall. This process gave all team members an insight into each other’s working preferences. This includes things we have in common, such as wanting inclusive, non-technical language and short meetings. It also covered areas where we differ. For example, some members of the team need uninterrupted quiet time to get work done, whereas others are happy to be interrupted to answer questions at any time.\nAt the end, everyone voted on the five things that mattered most to them. The results were put up on an A3 poster in the team’s desk space. It’s a living document that we’ll check our behaviour against regularly and continuously improve via team retrospectives.\nAgreeing how we’ll work together After the team charter session we agreed some of the finer details about working together. I came prepared with my own proposals for how we should work to ensure that there was a structure in place for day 1, but was open to alternative ideas from the team. As with the charter, we collectively own these processes, and they should be continuously improved based upon what we learn as we go along.\nWe decided to start with a Scrum process and one-week sprints. Some team members hadn’t worked with Scrum or in cross-functional agile teams before, so I gave the team an introduction to both of these topics and encouraged more experienced team members to share what had worked well for them before.\nTopics covered included:\nprioritisation and delivery processes meeting structures when, where and how to document our work how to use our various digital tools how to record planned leave A shared purpose The main purpose of a great product team is to solve problems for their users. So when we started our teams, the final thing we did was hold a full team workshop to explore who our users were, their needs, and how well those needs were currently being met. This gave us a shared understanding about the problems we were trying to solve and why they mattered.\nThis shared understanding about why our effort matters is key to team productivity. When they understand why what they’re doing is important, they see how it fits into the big picture and they believe in it, and they’ll be more motivated. This increased understanding of users and their needs also leads to more informed decision making, and makes the team less likely to get distracted by tasks which don’t add real value. These are some of the key reasons why we will keep the whole team involved in user research throughout the whole project.\nThis blog post was originally published on Inside GOV.UK\n","permalink":"https://alaniswright.com/blog/starting-up-a-new-team/","summary":"\u003cp\u003eGOV.UK was recently restructured to help us achieve our \u003ca href=\"https://insidegovuk.blog.gov.uk/2017/02/13/the-2017-to-2018-gov-uk-roadmap/\"\u003e2017/18 roadmap\u003c/a\u003e. As a delivery manager, I oversaw the formation of 2 new teams under the new roadmap: Content History and Worldwide Publishing. \u003cspan id=\"more-8854\"\u003e\u003c/span\u003eThe aim was to build happy, motivated and productive teams with a strong culture of agile user-centred delivery. This blog explains the steps we went through to start them up.\u003c/p\u003e","title":"Starting up a new team"},{"content":"Teams at GDS are free to pick the processes and tools that work for them. On the GOV.UK Publishing Platform, our Kanban process is supported by Trello. This is a follow-up to my blog post on How we use Kanban on the GOV.UK Publishing Platform team, and explains how we use Trello to support our Kanban process.\nWhat is Trello? Trello consists of boards, lists and cards. You can have as many lists as you want on a board, and as many cards as you want on a list. Cards contain all the information about the work to be done, and they are highly customisable with many different features such as checklists, commenting and attachments. A Trello board offers a great overview of your delivery because you can oversee multiple project stages all on one screen. It’s easy to add or edit lists and to move cards from one list to another.\nHow we use Trello We use Trello both for long-term planning and to manage our day-to-day work. We like to keep things simple, so to avoid information overload we’ve separated our work out into 4 boards.\nPlanning board The planning board is for work that’s yet to be prioritised.\nStories are proposed by someone in or outside of our team. Our story template helps people provide the right information. Periodically, our Tech Lead and Product Manager review proposed stories and triage them into other lists. If it’s something we’re not going to do they archive it.\nSupport work is for minor work requested by other teams or bugs identified by users. Mission work is for significant deliverables that will help deliver the GOV.UK goals. We try to strike a balance between long-term improvements and making sure the platform works for users now.\nStories that are next up for planning have been prioritised to be fully written, reviewed and estimated by the team at the next planning session. We usually have planning sessions every week, but we cancel these if there’s still too much work-in-progress.\nStories on the planning board are unlikely to be done any time in the next week. So we don’t put too much effort into writing, planning or breaking down stories until we think we’re going to have capacity to work on them. We minimise wasted effort by delaying delivery to the ‘last responsible moment’ – a key agile principle, meaning we don’t commit to decisions until we’ve investigated them as fully as possible.\nDoing board The doing board (or Kanban board) is for work that we’re doing now, or plan to start in the next week. This is the board the team reviews in daily standups, so it’s important that we keep it simple.\nNo story should enter this board until it’s ready to work on. That means:\nit has been prioritised by a product manager the problem that the story is trying to solve should be clearly understood by the team (the user need should be obvious) objective acceptance criteria should be written (checklists are great for these) the story should be estimated using story points (a number from 1 to 3 which indicates relative complexity) it should be properly labelled so we know what type of story it is (labels can be used as filters and help us generate useful statistics) Individuals add themselves as members to cards that they’re working on. Some also follow lists to get email notifications when a card moves to a new stage. The list headings are pretty self-explanatory, but they’re also defined in the board readme.\nSometimes we have repeatable tasks – chores that need to be done every month or week. Using the Card Repeater Power-Up, these automatically appear at the top of the backlog when they need to be done.\nDone board When a card is archived, you can still find it via search and links. But we like to keep a more visual record of the work we’ve delivered. So at the end of every month, we move all done cards to the done board. There’s a list for each month, so it’s easy to browse historical work. Again, to avoid clutter, we don’t keep more than a month’s worth of done work on the doing board.\nLong-Term Vision board Our long-term vision board gives us a high-level view of work that’s planned, in progress or done. Each list represents 2 to 3 months of work and usually corresponds to a stage on the roadmap. Each stage contains one or more big stories (or ‘epics’). For example ‘Implement End to End tests’ is a big piece of work that takes months to deliver. So we’ve broken it down into smaller stories, such as ‘Audit End-to End-Tests’, and referenced them in the description. Checklists allow us to keep track of how many stories still need to be done.\nExtending Trello We love Trello because it gives us the flexibility to easily change our delivery process. We use the following Google Chrome plugins to help us optimise Trello:\ncolour card titles for Trello (puts the label title in the label) kanban WIP for Trello (the bracketed number in the list title is the work-in-progress limit. If it’s met the list goes amber. If exceeded, the list goes red) projects for Trello (I use this plugin to explain why a card is blocked or what it is blocking) card numbers for Trello (useful for referring to cards quickly) slim lists for Trello (squeezes the whole board onto one screen) Measuring performance We use an unofficial Trello app called Corrello to measure useful statistics such as cycle time (the time spent working on a story), work-in-progress and velocity. Trello labels and Corrello’s customised reporting combined allow us to track how we’re performing for different types of stories. Putting story complexity estimations in brackets in the title also allows us to track progress by points rather than for each story individually.\nDon’t let a tool dictate how you work Many agile teams favour non-digital tools such as agile walls because of their flexibility. This flexibility is the same reason I love Trello.\nAt a recent retrospective the team identified that delayed product decisions were slowing down their progress. So we added a ‘product review’ stage to make it easier to visualise the Product Manager’s workload.\nAs it’s available online, it also doesn’t constrain us to all be working in the same place. Teams work better when they are colocated, but Trello makes it easy for people to work remotely some of the time.\nAgile teams work best when they self-organise. Trello makes it easy for us to determine our own way of working – whether that’s Kanban, Scrum or something else entirely.\nThis blog post was originally published on Inside GOV.UK\n","permalink":"https://alaniswright.com/blog/how-we-use-trello-on-the-gov-uk-publishing-platform-team/","summary":"\u003cp\u003eTeams at GDS are free to pick the processes and tools that work for them. On the GOV.UK Publishing Platform, our Kanban process is supported by \u003ca href=\"https://trello.com/\"\u003eTrello\u003c/a\u003e. \u003cspan id=\"more-8583\"\u003e\u003c/span\u003eThis is a follow-up to my blog post on \u003ca href=\"https://insidegovuk.blog.gov.uk/2017/02/15/how-we-use-kanban-on-the-gov-uk-publishing-platform-team/\"\u003eHow we use Kanban on the GOV.UK Publishing Platform team\u003c/a\u003e, and explains how we use Trello to support our Kanban process.\u003c/p\u003e","title":"How we use Trello on the GOV.UK Publishing Platform team"},{"content":"At GDS, we believe that self-organising teams create the best results. So we give each of our teams the autonomy to pick the delivery approach that works best for them. On the GOV.UK Publishing Platform, we use Kanban to help us manage the work we do.\nKanban was created by Toyota in 1950s Japan as a system to help them minimise waste in car manufacturing. More recently it was adapted for use by software teams. Nowadays it is one of the most popular and lightweight agile methodologies, and is in use throughout GDS on software and non-software teams alike.\nThere are five principles that we use in our Kanban system:\n1. Visualise our work All our work is visualised on a Kanban board. We use an online tool called Trello, but lots of other teams use a physical team wall instead. Each column represents a stage in our production process. Each card represents a problem that our development team are trying to solve. Cards flow from left to right, from “To do” on the far left all the way to “Done” on the far right.\nEach card contains detailed information about the work the team are doing. But at first glance we only show a brief title, categorisation labels and the avatar of any team members working on it. We keep it simple so that we can quickly convey to team members or stakeholders what we’re working on, what stage it’s at and who is working on what. Visualising our work also allows us to see how work flows through our system and spot areas that may need improving.\n2. Limit work in progress In each of our Trello lists, we’ve set a work-in-progress limit. For example, we can’t have any more than 4 cards in “doing” and 2 cards in “technical review”. So if the technical review list is at capacity, it becomes a bottleneck, stopping any more cards from getting pulled through from “doing”. This gives the team a clear visual message that they need to focus on the cards in technical review in order to unblock the system.\nLimiting work-in-progress makes sense because humans are bad at multitasking. When we work on too many things at once, we become less efficient. If we do fewer things, we can do them better, and often faster. Work-in-progress limits force teams to work together to stop bottlenecks emerging.\nThey can also be used to correct behavioural issues in a team. By having a low work-in-progress limit on Technical Review, we encourage team members to get into the habit of reviewing other people’s code before picking up new stories, which increases the efficiency of the team.\n3. Manage flow Our focus as a team is making work flow from “to do” to “done” as quickly as possible, allowing us to deliver value to our users early.\nCycle time is our measure of flow. It measures the time taken for a piece of work to be complete once started. Reducing our work-in-progress is one of the best ways to reduce cycle time. Another is to break big features down into smaller, consistently sized user stories, helping us to achieve predictability in our delivery.\n4. Make policies explicit In Kanban, ‘policies’ are the rules that define how our team works together, and like every other part of our process we try to keep them simple and visualise them.\nTwo common policies in Kanban teams are “definitions of done” and “acceptance criteria”. Definitions of done are criteria all pieces of work must meet before they can be considered done, or to move from one stage to another. Acceptance criteria are similar, except that they are unique to each story.\nWe also have a team charter which documents our collectively agreed team values and working practices. This helps new joiners to understand the way we work, and reminds existing team members of the actions we’ve agreed to.\n5. Improve collaboratively and evolve experimentally We use regular retrospectives to give everyone in the team a chance to identify and discuss potential improvements in a safe and supportive environment. We ask questions such as what’s working well, what’s not working so well, what have we learned and what can we change. Out of these discussions come actionable improvements we can use to try to make our process better.\nFor example, we recently added a policy that once a developer finishes a task, they should always try to pick up a task from the right-hand side of the board. These decisions are always experimental – if a policy doesn’t solve the problem it was introduced to address, it would be scrapped by the team at the earliest opportunity.\nIt’s ok to break the rules occasionally Work-in-progress limits and policies are not laws that we hold ourselves to rigidly. Sometimes, it makes sense to break the rules, so long as it’s a conscious decision. If and when this happens, it’s important for the team to reflect on whether this is a one-off exception, or whether the policy needs to be adapted.\nWhy Kanban works for us We operate in an uncertain environment, and we’re constantly learning more about the needs of our users. By releasing valuable new features continuously to our users, we get feedback quicker which gives us the information we need to make better decisions. And by delaying product decisions to the last responsible moment, we make the most of this knowledge and minimise waste in our process.\nWhy Kanban can be useful for a team new to agile The focus in Kanban is on evolutionary rather than revolutionary change. It takes the processes and policies a team has now, and adds work-in-progress limits, a focus on flow and a commitment to continuously improve over time. It creates the environment necessary for a self-organising team to evolve itself over time. That’s it. There’s no special job roles or meetings that are required for it to work. This makes it an effective tool for change management, because people generally dislike change that is externally imposed and find it easier to make progress one small step at a time. If you’re keen to start using Kanban but are new to the methodology, it makes sense to enlist the help of a delivery manager or agile coach.\nThis blog post was originally published on Inside GOV.UK\n","permalink":"https://alaniswright.com/blog/how-we-use-kanban-on-the-gov-uk-publishing-platform/","summary":"\u003cp\u003eAt GDS, we believe that self-organising teams create the best results. So we give each of our teams the autonomy to pick the \u003ca href=\"https://www.gov.uk/service-manual/agile-delivery/agile-methodologies#popular-agile-methods-explained\"\u003edelivery approach\u003c/a\u003e that works best for them. \u003cspan id=\"more-8495\"\u003e\u003c/span\u003eOn the GOV.UK Publishing Platform, we use Kanban to help us manage the work we do.\u003c/p\u003e","title":"How we use Kanban on the GOV.UK Publishing Platform"},{"content":" Wunderlist is a free-to-use task management tool. Available on desktop, web browsers, smartphone and more recently the Apple Watch, it allows you to stay organized wherever you are. Initially created in Germany it is one of my favorite productivity tools, and after it\u0026#8217;s recent acquisition by Microsoft, it should be around for a while to come. Here I explore how to use Wunderlist to keep yourself organised, and get things done. Getting things done 5 years ago, I read David Allen‘s famous book Getting Things Done (GTD). GTD is a 5 step system for collecting, processing, organising, reviewing and doing your tasks and projects – either in your personal / professional life or both. Allen noted that our minds are overrun with thoughts: groceries i need to buy, a voicemail i need to return, an interview i need to prepare for, a blog post i need to write (and the list goes on). A constant stream of thoughts like these stops us from focusing and makes us unproductive, uncreative and stressed. However, if each time one of these thoughts pop into our head we were to put it into a task management system, and we got into the habit of spending a little bit of time each day keeping this system organised, we would spend less time worrying and more time doing things that matter to us. This in a nutshell was Allen’s proposal.\nWhy Wunderlist? It is possible to implement GTD using a paper system, well worth considering for when the zombie apocalypse starts. Until that day, it’s probably best to find a digital solution. I experimented with different to-do list systems including Todoist, Google Tasks, Outlook Tasks and Remember the Milk, but ultimately I settled on Wunderlist for the following reasons:\nYou can access it anywhere – on your desktop/smartphone and via browser extensions It has all the features I need (and not too many more) – due dates, checklists, starred tasks and smart lists. It’s easy to use – some other task management tools are unnecessarily compex. Wunderlist is elegantly simple. It looks good – if you are going to look at it every day, attractiveness helps It’s free – some premium features available on Wunderlist Pro, but personally i have no need for them There’s lots of users and an active community – it’s unlikely they’ll stop supporting it any time soon (even more so now Microsoft have acquired it) Note that this post doesn’t describe a perfect implementation of GTD. It has been adapted to fit my own style of working and the features available to me on Wunderlist.\nWUNDERLIST STRUCTURE The two main components of Wunderlist are lists and tasks. You create a list. You add tasks to it. You can add detail to tasks (descriptions, dates, etc) and move tasks between lists. When you’re finished with a task, you tick the tickbox to mark it is complete. Simple.\nMy inbox view. I use folders to help give structure to my lists Lists I use Inbox. This is the default list from Wunderlist. It is where all new tasks go before they are processed. Every time I have an idea worth remembering or am assigned a task, I add it in here. Smartlists. Predefined intelligent lists from the Wunderlist team. These lists will scan all other lists and collate all tasks that are due today, due this week or starred. So these are the lists that i check regularly throughout the day to see what tasks need to be done next. Life lists. I have one life list for each major area of my life. Example life lists include, “health \u0026amp; fitness”, “career” and “admin \u0026amp; security”. Project lists. If I’m moving house, planning a holiday or building a website for a friend, I’ll usually create a project list for it. Shopping lists. I also have many shopping lists for things like groceries, music, films, books, etc. Waiting for. If a task is waiting for an action from someone else, it goes in here (usually with a due date so that I know when to send a reminder). To work / To Evernote. These folders are for tasks that need to be moved into a different system. I use Evernote for notes, and have a separate Wunderlist account for work. Archived lists. I’m a hoarder. I prefer to archive old lists rather than delete them. You never know when you might need it again. Managing a list Each list is treated like the product backlog tool used in agile project management (don’t worry if you don’t know what this is – all the parts that matter are explained below). All tasks are in priority order, with the most important/urgent at the top. Tasks near the top are small actionable items that can usually be done in under a few hours.A good example is “Do week 1 of Coursera web design course”. Tasks near the bottom are more like epics. Big placeholder tasks that will need to be broken down if and when they become a priority for me. A good example of an epic is “learn web design”. The next actionable item(s) or high priority tasks in each list should be starred. This moves them to the top of the list. It also means they can be viewed in the “starred items” list, allowing me to see all next actions across every list. It is important that the next actionable items are small enough to complete in a few hours. This makes it easier to avoid procrastination and gives me a psychological boost – the act of marking multiple tasks as complete in a day gives me more of a sense of achievement than getting half way through a mammoth task. If a task needs to be done by or needs my attention on a certain date, i’d give it a due date. GTD recommends giving due dates to all important tasks. Personally, I avoid going wild with due dates to give myself the flexibility to adapt to changing circumstances without feeling like I’ve missed a deadline. Task overview Each task has a brief title describing the action required. Any further information or URLs go into the notes. Any steps to complete get added as subtasks. If the task is a repeated task (eg. a reminder to exercise), it can be set to reappear every day. Every day it will automatically create a new tasks with a new due date. Wunderlist also has commenting, file upload and tagging functionality, but I don’t make use of these. In each task you can add notes, subtasks, files, dates and comments. THE PROCESS Unfortunately, software alone will not help you realise the productivity/ creativity/ stress-busting benefits of GTD. The most important part of implementing any task management system correctly is updating it regularly. If a system is out of date then it cannot be relied upon, and if it cannot be relied upon, you cannot have the peace of mind that comes from knowing that ideas and tasks are not being forgotten.\nTo avoid wasting time on un-neccessarily planning or letting my system go out of date, I try to always:\nPlan in detail for tomorrow today. Keep plans rough for next week and beyond. Do frequent small re-planning sessions rather than occasional bigger ones. “Plans are nothing; planning is everything.” – Dwight D. Eisenhower\nIn this section I describe 5 activities that help me stay in control:\nCollecting new tasks Daily review Doing and completing Weekly review Monthly grooming [av_table purpose=\u0026lsquo;tabular\u0026rsquo; pricing_table_design=\u0026lsquo;avia_pricing_default\u0026rsquo; pricing_hidden_cells=\u0026rsquo;\u0026rsquo; caption=\u0026rsquo;\u0026rsquo; responsive_styling=\u0026lsquo;avia_scrollable_table\u0026rsquo; av_uid=\u0026lsquo;av-2v4tfm\u0026rsquo;]\n1. Collecting new tasks New tasks and ideas can come from anywhere: conversations, meetings, emails, Facebook messages or just as ideas that pop into my head. Wherever they come from, they all end up in the same place: the inbox.\nI am constantly adding tasks to my inbox throughout the day. Most often, tasks are added via a widget on my phone, or the firefox/chrome extension. In both these cases there is an option to add to a specific folder, but I think it makes more sense to add tasks to the inbox first for two main reasons:\nLess clicks: if I add to the inbox there are only 2 clicks involved. However, if i have to change folder there are 4 clicks and a lag from my slow device. Both apps remember the previously selected folder added to: so if i select a folder other than inbox, i often accidentally put subsequent tasks in the wrong folder also. You can also add tasks by email. Just forward a mail to me@wunderlist.com (using the email address that you have registered with Wunderlist) and the email will be added as a task in your inbox.\nAt the end of each day in my daily review, I review all items in the inbox and move them into their relevant folder.\nHere\u0026#8217;s the Wunderlist Chrome extension in action. It automatically populates the title and notes field with meta data and URL from the page being visited. 2. Daily review Every day, I find it useful to do a daily review. This process usually takes no longer than 5-10 minutes, and I usually do it at the end of each day. Sometimes (usually on Friday or Saturday nights) I let the daily review slip to the next morning. Really, it doesn’t matter too much when you do it, as long as it happens every 24-48 hours. Most people find it best to do it at a regular time, mainly because it’s more likely to get done if you do it at the same time every day. The daily review usually includes the following actions:\nNew items added to my inbox need to be sorted into their relevant folders. I star them or give them a due date if they need to be done soon. Items that I will try to do next should be assigned a due date. For a daily review, I will usually only consider tasks that are overdue or starred. This saves lots of time as it means I don’t have to check all my lists every day. 3. Doing and completing Throughout the day I can view all of the tasks i need to do in the “Today” and “Week” smartlists.\n“Today” sorts everything by list. This can be frustrating if like me, you have many lists! It’s important to make sure that the most important lists are on the top if you use this view, which is why I keep my life and project lists at the top. It is easy to change the order of lists on Wunderlist – just drag and drop to rearrange. “Week” sorts everything by day, allowing to to manually change the order of each task. I’m a big fan of this feature, and I use the “week” view often for this reason, as it gives you granular control over the order in which things are done. Before discovering this, I would often move today’s tasks into a new list or even write the tasks down on paper so the order could be more easily controlled. The \u0026#8220;week\u0026#8221; smartlist. This is my favourite view, because you can reorder all the items due for today. 4. Weekly review Every week or so, I try to spend around 30 minutes thinking about what I want to achieve in the next week. My process here is:\ngo through each list starring priority items that i might want to do this week, decomposing larger tasks into smaller actionable items as I go review the starred list, and add due dates where possible By the end of my weekly review, I can see all my planned tasks for the coming week in my week smartlist. I also have all high priority tasks highlighted in my starred smartlist.\n5. Monthly grooming Every month or so – or more often than not, when I’m meant to be doing something really important but procrastinating instead – I take some time to review and groom my lists. My aim here is to find any tasks that are languishing near the bottom that I might want to make a priority.\nMaybe it’s time to start planning a holiday to that destination on my travel list, or to start reading that book I bought last month? Maybe there’s irrelevant items on my list that can be deleted? Maybe there’s an important task that I moved into the wrong list by mistake? List grooming is the time to reassess priorities for the coming months, and helps to remind me of the little things I want to do that might otherwise be forgotten.\nTIPS Separating work and play I keep separate accounts for my personal and professional life. Why? When I’m at home, I don’t want to have work tasks constantly popping into my consciousness and disturbing my peace. Instead, I keep one shared folder in each account that allows me to easily move tasks between accounts. So if I remember something about work when at home, I can add it to this folder and forget about it until I’m in the office.\nCalendar integrations Wunderlist’s integration with third party calendar’s is particularly useful, especially the Sunrise calendar. Sunrise has been designed with integrations in mind. For Wunderlist, this means all your Wunderlist tasks are displayed above your other calendar events, and you see when they’ve been completed.\nShared lists I have a shared groceries list with my girlfriend. A great idea in theory. In practice, it just means that I buy all the groceries!\nA FINAL WORD Wunderlist is a pleasure to use. The user experience is excellent and it has an attractive minimal design. The task management system I describe may look daunting at first, but it’s actually very simple. The key to making this work is doing regular small updates rather than occasional big ones. Make detailed plans for the next day. Less detail for next week. And less still for next month. Congratulations on reaching the end of my first blog post!\nGot any questions? Ask away in the comments. And feel free to share this if you’ve found it useful.\n","permalink":"https://alaniswright.com/blog/getting-things-done-with-wunderlist/","summary":"\u003cdiv\u003e\n  Wunderlist is a free-to-use task management tool.  Available on desktop, web browsers, smartphone and more recently the Apple Watch, it allows you to stay organized wherever you are.  Initially created in Germany it is one of my favorite productivity tools, and after it\u0026#8217;s recent acquisition by Microsoft, it should be around for a while to come.  Here I explore how to use Wunderlist to keep yourself organised, and get things done.\n\u003c/div\u003e","title":"Getting things done with Wunderlist"}]