{ "archive_path": "archive/1735279217.549799", "base_url": "staysaasy.com/engineering/2024/12/17/problem-driven-development.html", "basename": "problem-driven-development.html", "bookmarked_date": "2024-12-27 06:00", "canonical": { "archive_org_path": "https://web.archive.org/web/staysaasy.com/engineering/2024/12/17/problem-driven-development.html", "dom_path": "output.html", "favicon_path": "favicon.ico", "git_path": "git/", "google_favicon_path": "https://www.google.com/s2/favicons?domain=staysaasy.com", "headers_path": "headers.json", "htmltotext_path": "htmltotext.txt", "index_path": "index.html", "media_path": "media/", "mercury_path": "mercury/content.html", "pdf_path": "output.pdf", "readability_path": "readability/content.html", "screenshot_path": "screenshot.png", "singlefile_path": "singlefile.html", "warc_path": "warc/", "wget_path": null }, "domain": "staysaasy.com", "downloaded_at": "2024-12-27T06:00:21.967787+00:00", "downloaded_datestr": "2024-12-27 06:00", "extension": "html", "hash": "MEKTZET4BNKQX8N9RKK2", "history": { "archive_org": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://web.archive.org/save/https://staysaasy.com/engineering/2024/12/17/problem-driven-development.html" ], "cmd_version": "8.10.1", "end_ts": "2024-12-27T06:01:47.766066+00:00", "index_texts": null, "output": "https://web.archive.org/web/20241227060131/https://staysaasy.com/engineering/2024/12/17/problem-driven-development.html", "pwd": "/data/archive/1735279217.549799", "schema": "ArchiveResult", "start_ts": "2024-12-27T06:01:26.901726+00:00", "status": "succeeded" } ], "dom": [ { "cmd": [ "/usr/bin/chromium-browser", "--proxy-server=socks5://tor-socks-proxy:9150", "--disable-features=DarkMode", "--run-all-compositor-stages-before-draw", "--hide-scrollbars", "--autoplay-policy=no-user-gesture-required", "--no-first-run", "--use-fake-ui-for-media-stream", "--use-fake-device-for-media-stream", "--simulate-outdated-no-au='Tue, 31 Dec 2099 23:59:59 GMT'", "--headless=new", "--no-sandbox", "--no-zygote", "--disable-dev-shm-usage", "--disable-software-rasterizer", "--disable-sync", "--window-size=1440,2000", "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "--user-data-dir=/data/personas/Default/chrome_profile", "--profile-directory=Default", "--dump-dom", "https://staysaasy.com/engineering/2024/12/17/problem-driven-development.html" ], "cmd_version": "131.0.6778", "end_ts": "2024-12-27T06:00:57.717003+00:00", "index_texts": null, "output": "output.html", "pwd": "/data/archive/1735279217.549799", "schema": "ArchiveResult", "start_ts": "2024-12-27T06:00:33.634882+00:00", "status": "succeeded" } ], "favicon": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--output", "favicon.ico", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://www.google.com/s2/favicons?domain=staysaasy.com" ], "cmd_version": "8.10.1", "end_ts": "2024-12-27T06:00:27.582911+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1735279217.549799", "schema": "ArchiveResult", "start_ts": "2024-12-27T06:00:23.162093+00:00", "status": "succeeded" } ], "git": [], "headers": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://staysaasy.com/engineering/2024/12/17/problem-driven-development.html" ], "cmd_version": "8.10.1", "end_ts": "2024-12-27T06:00:28.076716+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1735279217.549799", "schema": "ArchiveResult", "start_ts": "2024-12-27T06:00:27.628867+00:00", "status": "succeeded" } ], "htmltotext": [ { "cmd": [ "(internal) archivebox.extractors.htmltotext", "./{singlefile,dom}.html" ], "cmd_version": "0.8.5rc51", "end_ts": "2024-12-27T06:01:19.872980+00:00", "index_texts": [ "(https://gmpg.org/xfn/11) (/assets/css/main.css) (/favicon.png) (/favicon.ico) (RSS) (https://staysaasy.com/feed.xml) (https://fonts.googleapis.com) (https://fonts.gstatic.com) (https://fonts.googleapis.com/css2?family=Lato:wght@400;700&family=Raleway:wght@600&display=swap) Problem Driven Development | Stay SaaSy (https://staysaasy.com/engineering/2024/12/17/problem-driven-development.html) (/) (/) Stay SaaSy A guide to scaling product & engineering teams from $0 to past $100M ARR. (/about.html) About (/ask_saasy.html) SaaSy Questions (/guides.html) Guides (/top_posts.html) Top Posts (https://blog.staysaasy.com/) Subscribe (https://twitter.com/staysaasy) @staysaasy (Subscribe) (/feed.xml) (Tags) (/tags.html) (Email) (mailto:hellostaysaasy@gmail.com) \u00a9 2024.\n Stay SaaSy. (/engineering/2024/12/17/problem-driven-development.html) Problem Driven Development 17 Dec 2024 \u2022\n\n \n \n \n\n \n engineering Figuring out what to do is a big part of senior tech roles. Senior Engineers and Engineering Managers often struggle to define technical roadmaps. Reasons include: There\u2019s little industry training on how to do it It can be daunting to prioritize against professional PMs who are specifically selected and trained to be persuasive Some organizations expect PMs to be responsible for all prioritization in teams, making Engineering roadmap ownership ambiguous Oftentimes, good technical vision can feel like it has to be some gift from the heavens or a skill you\u2019re born with. In reality, good technical vision is often a very simple and boring review of small amounts of data. An easy playbook for technical roadmap development is Problem Driven Development. In short, it means you develop your technical roadmap based on fixing things that are going wrong. It sounds simple, but it can be very empowering. Development Without Problems The classic first-attempt by EMs/Senior Engineers at roadmap development is to ask people what they think the team should do. This usually ends in sadness, because: Without time to think, people give bad answers. People over-index on opinions of people in positions of authority. \u201cThe Chief Architect said this was a good idea!\u201d They did, but they said that after a 2 minute chat, not after a deep understanding of the project and your roadmap. People offer solutions, not problems to solve. You get a list like: Upgrade our library version to the next minor version Refactor the Foo class to be composable Try out the new hot SaaS thing for X The implicit \u201cwe should do this because it solves X problem\u201d gets lost. Three sprints later people start debating the solution in abstract without ever remembering why they were doing it in the first place. The main fault with this approach is that it does not capture and solve the biggest problems. When you prioritize solutions, your job is done once everyone agrees to do your idea. \nYou can prioritize solutions for years and execute effectively without fixing your problems. When you prioritize problems, you prioritize fixing the issues you actually have. You cannot prioritize problems for years and execute effectively and not solve your problems. The a-ha moment is this: everything you\u2019re doing should be solving a problem. Align your team on the biggest problems you have. Derive your technical roadmap based on solving those problems. Periodically revisit your problems list to make sure it is still accurate. Problem Driven Development OK, if you\u2019re going to solve problems, you must figure out where they live. Most software teams have problems that live in the following places: Pages SLO violations Wasted time in projects/tasks Wasted time in development (e.g. slow CD) Application alerts Cost Change failures These failure repositories are auditable and you can directly build prioritized list of problems based off of them. When building a technical roadmap, you might end up with something like: We get too many pages. 80% of them are the WizBang service. We need to drive that to 0. We spend 12% of our time on manual tasks and we think we can reduce that by 50% with a month of work. SLOs have been great, no work needed. From here, you can figure out solutions you think solve these problems. It sounds very simple, but it\u2019s a powerful way of figuring out what to do. Problem Driven Development: Tech Debt Tech debt prioritization is notoriously fraught and challenging in industry. One major contributor to this is that engineers are pretty bad at saying why tech debt is important. Another contributor is that PMs often require PM-level prioritization research to prioritize against product work, which is unfair. Teams then get in fights and land on %-based tech debt allotments to not have to deal with each other. In any case, engineers ought to be better at doing reasonable due diligence on tech debt reasoning, e.g.: The class sucks, ok what problems does that cause? The problem is that it\u2019s hard to code in. OK how big of a problem is that? What do you mean? Besides it being gross, how much time are we wasting with it. Well we only change it like once every two years. OK so is that worth spending a month refactoring? No, but this other file has the same issue and we modify it every week and its change fail rate is super high. OK let\u2019s fix that one. Pretty quickly you can get to tech debt principles about wasted time, fail rates, and change frequency of issues if you frame things as solving problems and believe it can be done. Regular-sized tech debt should just be addressed as people code other work in that area of the codebase. But if you\u2019re asking a team to take the time to scope and prioritize work, you should have at least a miniscule amount of data to back up your claim. I\u2019ve often found myself high conviction on a piece of tech debt until I actually researched the value in this way. Problem Driven Development: Summary Problem Driven Development is a theory so simple it sounds obvious. But I\u2019ve seen many Engineers and Engineering Managers struggle to figure out what to do. And I\u2019ve seen even more not have a framework to say no to a Senior Engineer who loves a solution that doesn\u2019t solve a problem. Some next steps: If you find yourself in a position of needing to make a technical roadmap - find the problems, figure out the biggest ones, and make a plan to solve them. If you\u2019re a junior engineer wanting to work on your advocacy and vision, look at where your team\u2019s problems live. Don\u2019t stare at one class of code and lament the lack of design patterns. That\u2019s where a single problem lives. Instead, look at the repositories that host the patterns of behavior that justify prioritization. If you\u2019re an EM that wants your team to have more vision, expose and educate them on the problems you\u2019re having. I remember working at a major tech company and I was never remotely close to a holistic view of the problems my team was facing. If you only ever show people tickets, don\u2019t cry when you have a team full of ticket-takers. Whoever you are, always ground your team in the why of what you\u2019re doing. Once you lose sight of the problem, you\u2019ve definitely lost sight of the solution. Problem Driven Development: Appendix Problem Driven Development is basically just ersatz product management. One irony, however, is that PMs can do Problem Driven Development to a fault. Customer\u2019s problems are often much harder to get information about and take a very long time to gather. At the same time, your competitors might all have one feature that is clearly valuable that you don\u2019t have. In that case, you shouldn\u2019t be spending a bunch of time researching the problem just to get to the solution your competitors all have. More on this in a future post. Stay SaaSy everyone! Share to (https://twitter.com/intent/tweet?text=https://staysaasy.com/engineering/2024/12/17/problem-driven-development.html%20@staysaasy) Twitter , (https://news.ycombinator.com/submitlink?u=https://staysaasy.com/engineering/2024/12/17/problem-driven-development.html&t=Problem Driven Development) Hacker News , (http://www.linkedin.com/shareArticle?url=https%3A%2F%2Fstaysaasy.com%2Fengineering%2F2024%2F12%2F17%2Fproblem-driven-development.html) LinkedIn (/tags.html#engineering) engineering (/tags.html#problems) problems (/tags.html#technology) technology Recent Posts (/networking/2024/12/11/networking-for-people-who-dont-network.html) Networking For People Who Don't Network 11 Dec 2024 (/leadership/2024/11/19/executive-presence-part-2.html) A Practical Guide to Executive Presence: Earning Respect 19 Nov 2024 (/management/2024/11/10/giving-notice.html) Don't Act Differently After You Give Notice 10 Nov 2024 For new content, follow us at (https://twitter.com/staysaasy) @staysaasy or (https://blog.staysaasy.com/) subscribe via email . " ], "output": "htmltotext.txt", "pwd": "/data/archive/1735279217.549799", "schema": "ArchiveResult", "start_ts": "2024-12-27T06:01:19.841732+00:00", "status": "succeeded" } ], "media": [ { "cmd": [ "/usr/local/bin/yt-dlp", "--restrict-filenames", "--trim-filenames", "128", "--write-description", "--write-info-json", "--write-annotations", "--write-thumbnail", "--no-call-home", "--write-sub", "--write-auto-subs", "--convert-subs=srt", "--yes-playlist", "--continue", "--no-abort-on-error", "--ignore-errors", "--geo-bypass", "--add-metadata", "--format=(bv*+ba/b)[filesize<=750m][filesize_approx<=?750m]/(bv*+ba/b)", "--skip-download", "--cache-dir=/data/yt-dlp-cache/", "--cookies=/data/yt-dlp-cache/cookies.txt", "--proxy=socks5://tor-socks-proxy:9150", "--no-playlist", "https://staysaasy.com/engineering/2024/12/17/problem-driven-development.html" ], "cmd_version": "2024.10.7", "end_ts": "2024-12-27T06:01:26.845900+00:00", "index_texts": [], "output": "media/", "pwd": "/data/archive/1735279217.549799", "schema": "ArchiveResult", "start_ts": "2024-12-27T06:01:22.392683+00:00", "status": "succeeded" } ], "mercury": [ { "cmd": [ "/home/archivebox/.npm/bin/postlight-parser", "https://staysaasy.com/engineering/2024/12/17/problem-driven-development.html" ], "cmd_version": "2.2.3", "end_ts": "2024-12-27T06:01:19.798088+00:00", "index_texts": null, "output": "mercury/", "pwd": "/data/archive/1735279217.549799", "schema": "ArchiveResult", "start_ts": "2024-12-27T06:01:16.044363+00:00", "status": "succeeded" } ], "pdf": [], "readability": [ { "cmd": [ "/home/archivebox/.npm/bin/readability-extractor", "/tmp/tmp94uyf7wg", "https://staysaasy.com/engineering/2024/12/17/problem-driven-development.html" ], "cmd_version": "0.0.11", "end_ts": "2024-12-27T06:01:02.436695+00:00", "index_texts": [ "Figuring out what to do is a big part of senior tech roles. Senior Engineers and Engineering Managers often struggle to define technical roadmaps. Reasons include:\n\n There\u2019s little industry training on how to do it\n It can be daunting to prioritize against professional PMs who are specifically selected and trained to be persuasive\n Some organizations expect PMs to be responsible for all prioritization in teams, making Engineering roadmap ownership ambiguous\n\n\nOftentimes, good technical vision can feel like it has to be some gift from the heavens or a skill you\u2019re born with. In reality, good technical vision is often a very simple and boring review of small amounts of data.\n\nAn easy playbook for technical roadmap development is Problem Driven Development. In short, it means you develop your technical roadmap based on fixing things that are going wrong. It sounds simple, but it can be very empowering.\n\nDevelopment Without Problems\n\nThe classic first-attempt by EMs/Senior Engineers at roadmap development is to ask people what they think the team should do. This usually ends in sadness, because:\n\n Without time to think, people give bad answers.\n People over-index on opinions of people in positions of authority. \u201cThe Chief Architect said this was a good idea!\u201d They did, but they said that after a 2 minute chat, not after a deep understanding of the project and your roadmap.\n People offer solutions, not problems to solve.\n\n\nYou get a list like:\n\n Upgrade our library version to the next minor version\n Refactor the Foo class to be composable\n Try out the new hot SaaS thing for X\n\n\nThe implicit \u201cwe should do this because it solves X problem\u201d gets lost. Three sprints later people start debating the solution in abstract without ever remembering why they were doing it in the first place.\n\nThe main fault with this approach is that it does not capture and solve the biggest problems.\n\nWhen you prioritize solutions, your job is done once everyone agrees to do your idea. \nYou can prioritize solutions for years and execute effectively without fixing your problems.\n\nWhen you prioritize problems, you prioritize fixing the issues you actually have. You cannot prioritize problems for years and execute effectively and not solve your problems.\n\nThe a-ha moment is this: everything you\u2019re doing should be solving a problem. Align your team on the biggest problems you have. Derive your technical roadmap based on solving those problems. Periodically revisit your problems list to make sure it is still accurate.\n\nProblem Driven Development\n\nOK, if you\u2019re going to solve problems, you must figure out where they live. Most software teams have problems that live in the following places:\n\n Pages\n SLO violations\n Wasted time in projects/tasks\n Wasted time in development (e.g. slow CD)\n Application alerts\n Cost\n Change failures\n\n\nThese failure repositories are auditable and you can directly build prioritized list of problems based off of them. When building a technical roadmap, you might end up with something like:\n\n We get too many pages. 80% of them are the WizBang service. We need to drive that to 0.\n We spend 12% of our time on manual tasks and we think we can reduce that by 50% with a month of work.\n SLOs have been great, no work needed.\n\n\nFrom here, you can figure out solutions you think solve these problems. It sounds very simple, but it\u2019s a powerful way of figuring out what to do.\n\nProblem Driven Development: Tech Debt\n\nTech debt prioritization is notoriously fraught and challenging in industry. One major contributor to this is that engineers are pretty bad at saying why tech debt is important. Another contributor is that PMs often require PM-level prioritization research to prioritize against product work, which is unfair. Teams then get in fights and land on %-based tech debt allotments to not have to deal with each other.\n\nIn any case, engineers ought to be better at doing reasonable due diligence on tech debt reasoning, e.g.:\n\n The class sucks, ok what problems does that cause?\n The problem is that it\u2019s hard to code in.\n OK how big of a problem is that?\n What do you mean?\n Besides it being gross, how much time are we wasting with it.\n Well we only change it like once every two years.\n OK so is that worth spending a month refactoring?\n No, but this other file has the same issue and we modify it every week and its change fail rate is super high.\n OK let\u2019s fix that one.\n\n\nPretty quickly you can get to tech debt principles about wasted time, fail rates, and change frequency of issues if you frame things as solving problems and believe it can be done.\n\nRegular-sized tech debt should just be addressed as people code other work in that area of the codebase. But if you\u2019re asking a team to take the time to scope and prioritize work, you should have at least a miniscule amount of data to back up your claim. I\u2019ve often found myself high conviction on a piece of tech debt until I actually researched the value in this way.\n\nProblem Driven Development: Summary\n\nProblem Driven Development is a theory so simple it sounds obvious. But I\u2019ve seen many Engineers and Engineering Managers struggle to figure out what to do. And I\u2019ve seen even more not have a framework to say no to a Senior Engineer who loves a solution that doesn\u2019t solve a problem.\n\nSome next steps:\n\n If you find yourself in a position of needing to make a technical roadmap - find the problems, figure out the biggest ones, and make a plan to solve them.\n If you\u2019re a junior engineer wanting to work on your advocacy and vision, look at where your team\u2019s problems live. Don\u2019t stare at one class of code and lament the lack of design patterns. That\u2019s where a single problem lives. Instead, look at the repositories that host the patterns of behavior that justify prioritization.\n If you\u2019re an EM that wants your team to have more vision, expose and educate them on the problems you\u2019re having. I remember working at a major tech company and I was never remotely close to a holistic view of the problems my team was facing. If you only ever show people tickets, don\u2019t cry when you have a team full of ticket-takers.\n Whoever you are, always ground your team in the why of what you\u2019re doing. Once you lose sight of the problem, you\u2019ve definitely lost sight of the solution.\n\n\nProblem Driven Development: Appendix\n\nProblem Driven Development is basically just ersatz product management. One irony, however, is that PMs can do Problem Driven Development to a fault. Customer\u2019s problems are often much harder to get information about and take a very long time to gather. At the same time, your competitors might all have one feature that is clearly valuable that you don\u2019t have. In that case, you shouldn\u2019t be spending a bunch of time researching the problem just to get to the solution your competitors all have. More on this in a future post. Stay SaaSy everyone!" ], "output": "readability/", "pwd": "/data/archive/1735279217.549799", "schema": "ArchiveResult", "start_ts": "2024-12-27T06:00:59.070807+00:00", "status": "succeeded" } ], "screenshot": [], "singlefile": [], "title": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://staysaasy.com/engineering/2024/12/17/problem-driven-development.html" ], "cmd_version": "8.10.1", "end_ts": "2024-12-27T06:00:57.848665+00:00", "index_texts": null, "output": "Problem Driven Development | Stay SaaSy", "pwd": "/data/archive/1735279217.549799", "schema": "ArchiveResult", "start_ts": "2024-12-27T06:00:57.818455+00:00", "status": "succeeded" } ], "wget": [] }, "icons": null, "is_archived": true, "is_static": false, "latest": { "archive_org": "https://web.archive.org/web/20241227060131/https://staysaasy.com/engineering/2024/12/17/problem-driven-development.html", "dom": "output.html", "favicon": "favicon.ico", "git": null, "media": "media/", "pdf": null, "screenshot": null, "singlefile": null, "title": "Problem Driven Development | Stay SaaSy", "warc": null, "wget": null }, "link_dir": "/data/archive/1735279217.549799", "newest_archive_date": "2024-12-27T06:01:26.901726+00:00", "num_failures": 0, "num_outputs": 9, "oldest_archive_date": "2024-12-27T06:00:23.162093+00:00", "path": "/engineering/2024/12/17/problem-driven-development.html", "schema": "Link", "scheme": "https", "snapshot_abid": "snp_01JG3B72ZR05C8C1A401SMP41D", "snapshot_id": "ef12112e-282a-4b10-a3ad-f9ddf34b102d", "sources": [ "/data/sources/1735279215-import.txt" ], "tags": null, "tags_str": "", "timestamp": "1735279217.549799", "title": "Problem Driven Development | Stay SaaSy", "url": "https://staysaasy.com/engineering/2024/12/17/problem-driven-development.html" }