emissions<\/a>. Once the team has worked through one example, it becomes easier to repeat the method elsewhere.<\/p>\nBring the right mix of people<\/h2>\n
A useful workshop includes people who understand customer needs, product tradeoffs, and technical constraints. That usually means product managers, engineers, design or user experience leads, and sometimes operations, infrastructure, or data specialists. If the company has a sustainability lead, they can help frame the discussion, but the workshop should still be owned by the product and engineering teams who will use the output.<\/p>\n
It is also helpful to include someone who can challenge assumptions politely. In many teams, a workshop becomes more practical when one participant is comfortable asking how a proposed improvement would affect performance, customer experience, delivery time, or cost. Sustainability decisions are rarely isolated from those constraints, so the session should make room for them instead of pretending they do not exist.<\/p>\n
Set a clear outcome before anyone enters the room<\/h2>\n
People participate more actively when they know what the workshop is meant to produce. A clear outcome could be a shortlist of improvement ideas, a set of principles for future product decisions, a map of sustainability risks in one workflow, or a ranked list of actions to test.<\/p>\n
It helps to define the output in plain language. For example, the session could end with a decision about which product area to investigate further, which metrics to track, or which change should move into discovery or delivery next. The workshop should not end with vague agreement that sustainability is important. It should end with a next step that has an owner and a time frame.<\/p>\n
Prepare a short evidence pack<\/h2>\n
Before the workshop, gather only the information that will help the team reason well about the chosen topic. Too much data can slow the session down, but too little leaves people guessing. Useful inputs may include product usage patterns, hosting or infrastructure characteristics, known operational inefficiencies, customer behavior data, and any current sustainability goals the organization already tracks.<\/p>\n
The evidence pack should support discussion, not replace it. In many cases, a simple one page summary is enough if it explains the product context, the suspected sustainability hotspots, and the key uncertainty the team should explore. If you have no reliable measurements yet, be honest about that and frame the workshop as a way to identify what should be measured next.<\/p>\n
Design the workshop so it moves from awareness to decisions<\/h2>\n
A good session usually follows a sequence that helps people move from understanding to action. Start with a short framing section that explains why the topic matters for this product or system. Then move into a shared view of the current experience or workflow. After that, explore where the main environmental impacts or risks may sit. Finally, translate the discussion into options and decisions.<\/p>\n
This structure matters because many teams can discuss sustainability in principle, but struggle when asked to connect it to day to day product work. The workshop should make that connection explicit. If the team cannot see how sustainability changes a roadmap choice, a design choice, or a technical architecture choice, the session needs more concreteness, not more theory.<\/p>\n
Use the product journey as the main discussion tool<\/h2>\n
One of the most effective ways to run the workshop is to walk through the product journey from start to finish. That can mean the user journey, the data flow, the service lifecycle, or the engineering lifecycle, depending on the topic. The aim is to identify where unnecessary demand, waste, or inefficiency may appear.<\/p>\n
For a digital product, that journey might include discovery, onboarding, daily use, content loading, notifications, storage, support, and retirement. For a physical or hybrid product, the journey could include design, sourcing, manufacturing, distribution, use, repair, and end of life. The exact path matters less than the discipline of tracing impact across the full system instead of focusing on one isolated step.<\/p>\n
Questions that help the discussion stay concrete<\/h3>\n
Which parts of the workflow are used most often and therefore matter most?<\/p>\n
Where are users pushed toward unnecessary repeat actions or data use?<\/p>\n
What technical choices increase compute, storage, or network demand without clear user value?<\/p>\n
Which steps make repair, reuse, or long term use harder than they need to be?<\/p>\n
What would we change if sustainability had the same priority as speed, quality, and cost?<\/p>\n
Make tradeoffs explicit instead of assuming they are bad<\/h2>\n
Product and engineering teams often hesitate to discuss sustainability because they expect a hidden cost in usability or reliability. That concern is reasonable. A workshop becomes more valuable when it makes tradeoffs visible and testable rather than treating them as arguments to avoid.<\/p>\n
For example, a lower data feature may reduce resource use but also affect responsiveness. A simpler interface may reduce repeated user actions but require more careful onboarding. A more durable technical approach may take longer to build but lower maintenance burden later. The point is not to claim every sustainability improvement is free. The point is to compare options honestly and choose the one with the best combined outcome.<\/p>\n
Keep metrics simple enough to use<\/h2>\n
The workshop does not need a full life cycle assessment to be useful. In many teams, the first step is defining a small set of practical indicators that can be tracked consistently. Depending on the product, these might include usage efficiency, server or compute demand, storage growth, device lifespan, repairability, return rates, support burden, or the frequency of unnecessary user actions.<\/p>\n
If carbon data is available and credible, it can be part of the discussion. If it is not, do not force precision that the team cannot support. It is better to identify a proxy metric that can guide design choices than to use a number that looks exact but is weakly grounded. The workshop should help the team decide what is worth measuring next, not pretend all impact can be quantified immediately.<\/p>\n
Facilitate the session so quieter voices are heard<\/h2>\n
A strong facilitator makes a big difference. Product and engineering meetings can be dominated by the most confident speakers, which can narrow the range of ideas. The facilitator should make space for different viewpoints, keep the discussion tied to the chosen scope, and stop the conversation from drifting into general statements about corporate responsibility.<\/p>\n
It helps to ask people to speak from their own area of expertise. Engineers can explain technical constraints, product managers can explain customer tradeoffs, and designers can explain behavior and interaction patterns. When each role contributes from its perspective, the team is more likely to surface options that none of them would have identified alone.<\/p>\n
Translate the workshop into a backlog the team can actually use<\/h2>\n
The output should be more than notes. At the end of the session, turn the discussion into a short backlog of actions. Some items may be immediate product changes. Others may be research tasks, technical experiments, or measurement work. A few may become longer term design principles.<\/p>\n
The backlog works best when each item has an owner, a purpose, and a next step. If the team agrees to reduce unnecessary data transfer, for example, define who will investigate the current cause, which part of the product is in scope, and what success would look like. If the team wants to reduce waste from a feature, define what user behavior or technical pattern needs to change before work begins.<\/p>\n
This step matters because workshops often create energy but no follow through. A short, realistic action list gives the team something to review later and keeps sustainability from disappearing once the meeting ends.<\/p>\n
Plan for follow up after the workshop<\/h2>\n
The workshop is only useful if the team revisits its output. Schedule a follow up session or integrate the actions into an existing product or engineering review cycle. That follow up can be used to check whether the team gathered the right data, tested any ideas, or changed any priorities.<\/p>\n
If the team found the discussion valuable, repeat the format on another product area. Over time, the organization can build a simple internal playbook for sustainability work. That playbook may include the workshop agenda, the evidence pack template, the questions the team asks, and the way decisions are recorded.<\/p>\n
Repeated use is important because sustainability maturity usually develops through practice, not one off events. A single workshop may spark interest, but a repeatable process is what makes the work part of normal product and engineering decision making.<\/p>\n
Common mistakes to avoid<\/h2>\n
One common mistake is treating the workshop like a presentation. If the facilitator spends most of the time speaking, the team will not do the reasoning work the session is meant to support. Another mistake is choosing a topic that is too broad, which makes it hard to reach any useful decisions. A third mistake is focusing only on carbon when the better lens may be resource use, durability, repairability, or waste reduction.<\/p>\n
It is also easy to make the workshop feel disconnected from the team\u2019s real priorities. If the chosen topic has nothing to do with roadmap pressure, customer needs, or technical debt, the session will struggle to produce useful outcomes. Finally, avoid ending with enthusiasm but no ownership. Without explicit next steps, the workshop becomes a nice conversation rather than a change in how the team works.<\/p>\n
What a strong workshop usually leaves behind<\/h2>\n
When the session works well, people leave with a clearer view of where sustainability fits into their work. They understand which product or engineering decisions matter most, which uncertainties still need evidence, and what they can do next without waiting for a separate initiative.<\/p>\n
That shift is the real value of the workshop. It helps teams move from broad intent to practical judgment. Over time, that judgment improves product choices, engineering habits, and the organization\u2019s ability to build with sustainability in mind from the start.<\/p>\n
If you want the workshop to become part of normal practice, make the next one easier to run than the first. Keep the scope tight, keep the evidence relevant, and keep the output tied to a real decision the team can own.<\/p>\n","protected":false},"excerpt":{"rendered":"
A sustainability workshop can help product and engineering teams turn broad environmental goals into concrete product decisions. This article explains how to plan the session, choose the right participants, structure the discussion, and leave with actions the team can actually use.<\/p>\n","protected":false},"author":1,"featured_media":755,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[203,314,5],"tags":[],"class_list":["post-754","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-engineering","category-product-management","category-sustainability"],"_links":{"self":[{"href":"https:\/\/dedaloai.com\/news\/wp-json\/wp\/v2\/posts\/754","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dedaloai.com\/news\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dedaloai.com\/news\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dedaloai.com\/news\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dedaloai.com\/news\/wp-json\/wp\/v2\/comments?post=754"}],"version-history":[{"count":1,"href":"https:\/\/dedaloai.com\/news\/wp-json\/wp\/v2\/posts\/754\/revisions"}],"predecessor-version":[{"id":756,"href":"https:\/\/dedaloai.com\/news\/wp-json\/wp\/v2\/posts\/754\/revisions\/756"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/dedaloai.com\/news\/wp-json\/wp\/v2\/media\/755"}],"wp:attachment":[{"href":"https:\/\/dedaloai.com\/news\/wp-json\/wp\/v2\/media?parent=754"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dedaloai.com\/news\/wp-json\/wp\/v2\/categories?post=754"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dedaloai.com\/news\/wp-json\/wp\/v2\/tags?post=754"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}