Joplin -> Obsidian

To fit my file-system-based + data ownership requirements, I ended up switching to Obsidian. It’s a tool I’ve read a lot of people praising, and after a brief testing period, I’ve been gradually switching my note-taking flows one by one.

The process to migrate from Joplin to Obsidian is fairly simple:

1. Set up your new Obsidian vault.
   • I’m syncing it through Dropbox simply by creating my vault in a synced folder. I’m not using my notes on mobile, but the Remotely Save plugin would work if I wanted to.
   • I’ve added a few plugins to make my life easy:
     • Find orphaned images: to clean up the trash images from webclips (like all those useless Substack avatars)
     • Local backup: to have a proper backup besides Dropbox syncing
     • Local images plus: to download images when clipping from the  web, to make sure that when an article disappears, I still have the full article with all the imagery
     • Tag wrangler: to make managing tags easier
     • Omnnisearch: faster search results
2. Export Joplin notebooks with the “Markdown + Front matter” option
   • I’ve started with my webclips folder, as it’s quite chunky (2500+ notes), and needed some tidying up.
3. Tidy up the exported folder. The pro/con of working with files: import is just copying files, but clean up is up to the user
   • On Mac, the filenames were truncated, which caused problems for some weird note titles, and images which were disconnected from the original files in the process - I fixed as much as I could with scripts, the rest I’ll just fix as I go
   • Moved the images and other files in a separate _resources folder to the note folder and updated note files with the image locations
   • Updated tags: Joplin accepted tags with spaces, Obsidian doesn’t like that, so more scripts to help with that

A thing I notice is how Obsidian is better at nurturing my data-hoarding hobby, for once, tag management is much nicer. In Joplin (and even earlier in Evernote), I let my tagging grow organically, but now I spent some time in structuring my tags better, which also helps in organising how I think about topics.

Pocket -> Instapaper

Last year, after Mozilla decided to close Pocket, I ended up with a stash of over 4000 “read-it-later” links. Besides using Instapaper, I’m also saving fewer things to my reading backlog - both curating things faster and throwing away uninteresting things. Meanwhile, I’m reading through the past items, relying on Obsidian’s better tagging and web clipper tools, plus on Claude to help with some of the more tedious reviews, like articles broken up to multiple pages.

Claude Code

After testing multiple agentic tools, I settled on using & subscribing to Claude Code, opting for learning one tool in depth, rather than multiple ones superficially.

I’m still figuring out the best approach. I’m sometimes chatting with Claude on the web for quick questions, using Claude Code from the terminal most of the time (Ghostty is great), and opening VSCode to see files and make edits. Generally, the terminal feels the fastest and most information-dense.

How I use Claude Code is all over the place: making side projects, exploring creative ideas, organizing and researching information. Like this week, I’ve made a simple command to summarise YouTube videos with timelines to explore (I like to read much better than to watch a long-form video). A lot of things I’ve considered hard or time-consuming in the past turned into something to pick up and finish between my morning yoga and the first meeting of the day, removing the need to learn uninteresting things or go through tedious processes.

In many ways this interaction (or maybe better described as meta-interaction) reminds me of modern mobile games: the energy mechanism (the tokens might run out), the sorta slot-machine like waiting for results (though Opus 4.6 is much more consistent than earlier versions), the easy to enter a flow state (“Huh, I’ve been working on this question for 4 hours now?”).

The cognitive exhaustion / decision fatigue after a longer session is the most interesting effect I observed sofar. But I also feel more energised, with much of the tedium removed from making things.

So fun, but needs mindfulness on how to use responsibly - just because results are easy, sometimes the goal was not to get easy results in the first place. Kinda like how having a “2nd brain” in notes makes people do more thinking instead of doing, having such tools can make people doing more (instead of thinking).

My current rule of thumbs with agentic systems is:

• If I intend something I make to be read / used by humans, I should mostly craft ideas, words, and pixels myself as much as possible. If that’s not feasible, I’ll build a separate and appropriate workflow to establish systems and not just launch rapid-fire slop.
• Spend more social and 2nd brain time (here is how Obsidian helps) to balance out agentic time.

Usually, people go through three phases in expressing their intentions.

• People start with a low intention and are more focused on expressing it. Early career professionals (junior designers are in this phase, thinking a lot about how things look, how tools work, what style to use. Additionally, there are people in this phase who don’t value design as much, thinking it’s shallow and superficial, and that using a good enough front-end framework is enough for design. “Just make it look nice” or “Copy what Notion does” are attempts at expressing an intention that was already unclear. Intention is unformed, without shape, it’s more of a wish for something to exist. It’s why “just generate a website with AI” style efforts fail.
• Over time, some will get better at having a clear intention. Mid to senior-level designers and people who develop a good product sense will get here, they have a clear intention that they can also express with their tools (like design, writing, or code). There is an internal image of what good looks like and how it should be expressed.
• Unfortunately, most things (almost certainly most software worth creating) need multiple perspectives coming from multiple people. These perspectives have to come together in a shared intention. The task of the person designing changes is to create a shared intention, a common understanding, combining the clear (or not so clear) individual intentions that can be expressed. Senior to senior+ designers, driver contributors are in this phase.

AI tools (more specifically, the current breed of generative tools) don’t carry an intention. They create plausible things based on the input they are getting. The output will be probably right most of the time (especially as we get better and better tools). But there is no innate intention, so they also cannot create or propagate a shared intention across multiple interactions with multiple people.

AI tools have some use in expression, as they can quickly express an intent. If the intent is well-formed, the expression will get better. But a well-formed intent is also an act of expression. If people try to ask the tool to shape the intent, it will fail, mostly since AI tools are not great at creating high-density expression. At least writing well, but also designing and coding well, are still highly useful expressions of intent that fit into a chain of tasks, maybe containing AI tools down the line.

☕ Combating groupthink

Products might fail for many reasons. One of them is if the team ignores feedback or evidence and goes all in on an idea that, in the end, was not the right one. While there could be approach or organisational issues, a reason for failure is also if the team focuses too much on internal agreement, that is, groupthink, in their decisions.

Groupthink is a phenomenon of social decision-making, when the group members value internal harmony and lack of conflicts higher than great outcomes. Because agreement can be based, for example, on the loudest voice or the lowest common denominator, this can lead to mediocre decisions, a lack of innovation, and ultimately wasted resources.

The need of humans to be accepted by their groups makes this phenomenon extremely common in situations where disagreement might lead to social rejection. Since product development is usually a high-pressure situation, there are quite frequent opportunities for friction between team members in almost every step of the process, like interpreting research results, brainstorming ideas, prioritising, or reviewing design choices.

Why the group ends up with a mediocre choice is best understood from social dynamics, deadlines are tight, there is a lot of external pressure, there are dominant personalities in the team, dissent or disagreement isn’t encouraged, or the team is lacking diversity of thinking.

While designers are not always responsible for facilitating disagreements, since by its nature, design questions highlight internal problems, they often find themselves trying to figure out the group consensus.

Besides finding themselves in these situations, the nature of the design process also lends itself to facilitating discussions. Alternating convergent and divergent thinking is a key piece of handling groupthink. When there is space to analyse data and mature ideas outside of conversations (divergent thinking), it’ll be much easier to articulate new ideas or connect the dots in a discussion (convergent thinking).

The convergent — divergent thinking is not our only tool. Holding structured critiques helps in better discussions, not only in design, while advocating for user centricity helps understanding and accepting how data from outside of the immediate group can be helpful, for example, via user research.

As a side note, while a team’s decision-making processes are important to scrutinise, groupthink might start much earlier, when teams are formed. When designers hire other designers like them (focusing on similar skills or a similar background), it can lead unintentionally to a group that rarely looks for information from the outside and falls into the groupthink pattern. A purposeful hiring process is the first step to avoid this.

Fostering psychological safety is a tool for leaders to improve decisions. This makes giving a fair stage to every viewpoint part of the culture. There are a few things any leader can start doing:

• Leadership’s role is to be a role model for being open and respectful to opinions other than their own.
• Encourage dissent by not only providing a space, but explicitly asking for opposing ideas, as that makes it easier to articulate things that go against the majority opinion. Workshop plays like pre-mortems help solidify the point that failures need to be discussed.
• Blameless post-mortems, after something happens, focus on learning from mistakes.
• Celebrate constructive conflict by recognising how challenging ideas and having a healthy debate about options lead to better outcomes.
• Empower junior team members, since they might be reluctant to speak up and question more senior members.

However, the above only works if the team’s roles are set up to do this.

• Facilitation needs to be a clear role, to have someone who guides the discussion and makes sure everyone gets to talk. Rotating the facilitator (like having it on a schedule, or choosing randomly at the beginning of the session) helps work on problems with different discussion patterns.
• Devil’s advocate can be defined as a role tasked with challenging ideas or coming up with counterarguments.
• Cross-functional participants provide new perspectives and generally improve collaboration across teams.

These tactics won’t easily solve all problems with groupthink; besides being mindful when creating team practices and rituals, it’s also a continuous effort that needs leadership. However, open dialogue and diverse perspectives are powerful tools to create truly impactful products.

This is a post from my newsletter, 9am26, subscribe here:

🍪 Things to snack on

Groupthink by Wikipedia Wikipedia, as always, has a good overview of the topic, adding some history too, including the insight that the effect is not that well researched and understood, but has plenty of anecdotal evidence. There is also a longer section on prevention, with some really nice advice, like inviting experts from outside the group to get a different, out-group perspective. Diversity of all kinds is also instrumental in preventing groupthink. Individuals with varying backgrounds, thought, professional and life experiences etc. can offer unique perspectives and challenge assumptions.

♣︎

Groupthink: when collective decisions go wrong by Dr. Hannah Rose A few more general examples of how groupthink impacts our daily life, and strategies to avoid it (for example, assigning some group members to play devil’s advocate). As in work situations, in non-business contexts it also helps to put a little structure into decisions, like treating ideas as something transitional, but not the final solutions, until the other members can articulate concerns. Groupthink can be responsible for collective decisions that are irrational, risky or even illegal. In a group setting in which cohesion and a positive social opinion of the group are highly valued, members put a lot of energy into ensuring harmony within the group.

♣︎

Groupthink in UX Work by Samhita Tankala A nice summary of symptoms of groupthink in design contexts (collective rationalisation, illusion of unanimity, self-censorship, and direct pressure on dissenters), with some guidelines to prevent it in UX activities. The guidelines are grouped by various scenarios (like during ideation or in remote environments), which in itself also describes the common situation where groupthink can arise. Groups benefit from hearing diverse perspectives. For that to happen, group members have to feel comfortable in sharing their thoughts. We need to intentionally build awareness around groupthink, acknowledge that it occurs in group settings, and create a work environment that prevents it from happening.

♣︎

Common-Knowledge Effect: A Harmful Bias in Team Decision Making by Evan Sunwall While team decisions are generally better, the diversity of perspectives is often wasted, as team members are more comfortable discussing information they all already understand (the common-knowledge effect) and underutilise information only a few members know. One result of this phenomenon is groupthink. The article has a nice example scenario of how this happens, what biases are in play, and what some strategies to mitigate the effect. As counterintuitive as it seems, increasing the number of people involved in a difficult decision will likely decrease decision-making quality. Whatever unique knowledge individuals could offer to deliberations often goes unshared or disregarded.

There are three ways how automation can change a person’s job: do more of the same thing, do the same thing better, and do different things.

Better efficiency: automation helps to do more of the same given resources like time. Things like repetitive tasks or time-consuming tasks are good targets for this kinda of improvement.

• For example, in product design the new tools are promising to help create more screens faster, and go from an idea straight to a prototype, these are all efficiency improvements.
• As a pitfall for better efficiency, it’s often just part of the process that is easy to automate, and the parts that are harder to automate will get even harder, requiring more attention from whoever is doing the task. For most people doing the job, this will also mean more pressure to deliver more things in the same amount of time.
• A historical parallel would be the telephone and email that didn’t decrease the amount of communication, but rather allowed for both more communication and more complex systems established with communication.
• Design considerations would be to help the users to connect tasks to the overall workflow better, and get enough insight on the status of the automation runs to intervene if needed. So humans should be able to stay in the loop easily.

Better effectiveness: automation can improve precision and quality, following established standards more closely and making time for the person to create more personalized experiences.

• In design tools, I see less focus on this type of automation, maybe since quality is harder to measure. Most tools don’t seem to be focusing on reducing preventable errors or even applying heuristics meaningfully, outside of trying to follow design systems more closely.
• Since quality often depends on nuance, judgment, and understanding the complexity of human motivations and needs, it doesn’t always lend itself to easy automation. Automation bias leads the remaining people in the system to be less vigilant of possible errors.
• A historical parallel would be the standardized manufacturing process, which enabled more precise machinery that led to more consistent product quality.
• Design considerations: thinking about the existing workflow, what drives quality, and augmenting the human in the loop with new capabilities around the quality attributes helps to create centaurs building on both sides’ strengths.

Shift role and focus: with automation doing the more basic things, people can do higher value and more interdisciplinary things.

• In product design the shifting role is part of the discussion when designers are described as having to code, having to know more of the overall product development process, and needing to do more strategic and often cross-team work beyond their immediate product teams.
• Obviously, the pitfall is, that workflows, companies and maybe even what people would want to do often don’t enable shifting of roles or enabling a bigger focus, which leads to people getting laid off.
• A historical parallel could be how secretaries moved from typing letters to a broader role of managing offices and supporting executives and teams.
• Designing for shifting roles usually goes beyond immediate product design, as it requires changes more on the organisational level. However, with new people doing different things differently, there is an even greater need for thoughtful product design, connecting workflows across different disciplines.

A special mention should be how automation might enable new users to perform the same tasks. Like providing customer service in a foreign language, or improved accessibility to tools.

• Team performance: This is a summary of each team member’s manager’s reports. Opens up the conversation on how the manager makes sure the team members are successful, and if they are not, what the manager does to change the situation.
• Team engagement: this is more about the relationship to reports, whether is it developing or stagnating, and how well the team sees the manager as the go-to person to solve problems. If the reports are working together as a team, it’s also about how the team is behaving beyond individuals.
• Product ownership: own the products in their domain, and have a good understanding of challenges, projects, plans, visions, and relation to the overall strategy. Also includes being able to connect the dots across initiatives and being a good sparring partner in the domain. Helps the manager of managers to avoid being surprised by random questions from stakeholders.
• Stakeholder management: How well the manager can build and maintain relationships with stakeholders. This helps get things done especially for designers embedded in product teams, but more generally smooths out projects.
• Initiatives: Things not falling under the other categories, but impacting performance in other areas. Extra product, operations, design team related, or any other work the manager is doing. Also making sure to overwhelm managers.

What I like about these points, is that aspiring seniors who are eyeing the management track can also take a hint on what they need to get better at.

☕ Discovery is more than user research

Discovery in product development is a group of activities to help the team understand what is the right product to build. As Teresa Torres puts it: the work we do to make decisions about what to build.

What gets built is defined by decisions on multiple levels (like company strategy, legal requirements, current tech stack, and user need) by multiple people, so user research can’t be the only input to those decisions. This is why figuring out what the right product needs involvement from all members of a product team (the product trio approach), and thus a combination of activities.

Product discovery is paired with delivery, which makes sure the product is built right — the two parts of dual-track agile. Once the product team discovers what they want to build (as defined by prototypes, designs, specs, PRDs or other similar artefacts), they deliver the solution, caring about implementation, documentation, and design details. The beauty of the dual-track approach is, that while the two parts appear to waterfall, ideas from discovery inform delivery continuously, while learning from delivery drives further discovery, creating an interplay between the two sides.

Sometimes teams turn to the building and fail fast approach to delivering something directly in production. It’s important to realize, that discovery will still happen, but only after decisions are made and things have been built. This later understanding of risks is always more costly, as decisions will be harder to change both practically (for example technical choices were made), and mentally (sunken cost fallacy).

On a high level, the team looks at their basic questions and assumptions around an opportunity in discovery to address risks and gets insights about them. The tricky part is to cover all aspects, since assumptions come in many flavors and carry multiple types of risks within them.

When it comes to developing products, there are four types of risks product teams need to take care of: business fit, value, usability, and feasibility.

• Business fit (or viability) covers all things related to the broader business. Does the solution fit into the portfolio strategy? Are legal, financial, and ethical issues handled? Can it integrate with other products in the portfolio? Is this the right time to bring it to the market? Is there a budget available for go to market activities?
• Value is all about if there is a clear product-market fit with the potential users. Does the solution address a clear user need? How does it fit into the user’s existing context? Are there enough potential users to have a good return of investment? If this is a paid product, does the cost justify the functionality for the users?
• Usability covers all the experience-related questions. Is the solution easily understood and learnable? Does it fit with the users’ ways of working and expectations? Can it deliver what it promises? Is it much better than the current approach to justify the switching costs? Would the users want to switch to or use it?
• Feasibility is related to the implementation and technical constraints. Is the solution possible to build? Can the team build it? Does building it take a reasonable amount of time compared to possible value? How costly is it to deploy? How difficult is it to maintain? How much support will either the users or the implementation need?

As a side note, these aspects are related: for example, with high value previously unfeasible (for example too expensive) solutions can turn into feasible once the associated risks are understood and mitigation strategies tried during discovery. So working on each of these risks should be tightly connected.

User research is very helpful to address some of these questions, but it’s not the only activity the team needs to perform to completely understand the possible solution. Some of the above questions will need other activities (like making technical decisions or figuring out design constraints) and thus involvement from the broader team.

While discovery helps in making better choices, sometimes the problem is trivial, well-understood, or is firmly in a space the team already understands well (for example adding a new payment method to a checkout form). We want discovery to focus on more meaty problems, so in these cases, it can be omitted.

To make sure discovery is encompassing, discussing opportunities should start with a kick-off including the product trio, other relevant experts, and stakeholders. The goal is to give a better frame of the problems at hand, gather known insights, and make a list of assumptions the group has to drive potential solutions. During discovery, these points would be further expanded as the team learns and understands the problem space better. For each assumption, a learning path can be established (like talking to potential customers, creating technical POCs, doing root cause analysis, or sketching up prototypes).

If the outcome of discovery is the decisions defining what the product team needs to build, discovery activities need to cover all aspects of those decisions.

This is a post from my newsletter, 9am26, subscribe here:

🍪 Things to snack on

Product discovery is paired with delivery in a development process usually named dual track agile. Jeff Patton’s Dual Track Development is not Duel Track describes the origin of the term, the differences between discovery and delivery, and how product teams need to do both activities at the same time.

♠

Besides offering a good primer on discovery, The critical role of discovery in product development by Matthew Godfrey offers a view on collaboration in discovery. It’s typically led by the product manager, product designer and technical lead, while other disciplines can join temporarily the efforts.

♡

If discovery is building the right product, it’s important to understand how the wrong product could be built. This is where understanding the various risk types is helpful. Marty Cagan describes four types of risks in Product Risk Taxonomy: value, usability, feasibility, and viability. By covering each of these risks, product teams discover what product they should build.

♣︎

Chris Jones in Product Discovery: Pitfalls and Anti-Patterns categorizes discovery mistakes into 6 categories. These are: Confirmation-biased discovery (focusing on an already established solution), product-as-a-prototype discovery (mistaken delivery), partial-team discovery (doesn’t address all risks), one-dimensional discovery (focused on a single method or approach), big-bang discovery (lacking continuity), outsourced discovery (expecting others can learn instead of us). There are also some tips to get it right.

♢

The ultimate result of discovery is better outcomes for the users. This is the main reason for handling discovery as a team-level activity, rather than focusing only on specific aspects. In Doing Discovery Well: How to Measure and Guide Your Team, Teresa Torres shows that the good lagging indicator for discovery is how well the team reaches their desired outcome. As a more immediate measure, the cycle time between activities can be used, like how often the team talks to a user, runs an experiment or throws away solutions.

So I was delighted to learn about idea to structure goals recently. Well-being can be thought of as system maintenance. As the idea goes: if you don’t schedule maintaining your equipment, your equipment will schedule maintenance for you. For example: if you don’t eat well enough your long term health might suffer and you will get sick. Or: if you don’t learn more your career might suffer and you will struggle to find new opportunities.

The analogy seems especially helpful, as it also helps categorizing goals according to the four types of maintenance (there are multiple types of maintenance framework, but this is the most helpful to me):

• Corrective: fixing current problems. Hitting my sleep goals, spending time to keep track of things would fit here, like not letting admin work piling up. This would be a type of goal that I frequently feel the pain of, but rarely acknowledge it’s a problem to focus on, so might need to set or reframe goals around to correct current problems.
• Preventative: avoiding future problems. Focusing on physical and mental health goals fall here, and usually an easy category to have goals around.
• Adaptative: to re-adjusting to changes. This is something that gets lost with yearly planning, but shows meta goals like reviewing progress and adjusting targets based on changes is important and should be part personal goal setting.
• Perfective: to work towards a better system. Getting better at certain design practices, or building a better world through teaching would both fall into this category.

Thinking in these types is helpful, as they uncovered efforts that I’ve been already doing, and let me think about my overall goals in a new light - how exactly they contribute to my overall well-being.

Addy Osmani in The 70% problem: Hard truths about AI-assisted coding:

This “70% problem” suggests that current AI coding tools are best viewed as:

• Prototyping accelerators for experienced developers
• Learning aids for those committed to understanding development
• MVP generators for validating ideas quickly

This seems very similar to the trajectory of AI design tools. There is a difference though: code can be analyzed and understood, while generated UIs are much harder to predict how they will work, that is: how people will react once they start to use. UX and usability cannot be easily AI-ed, since they need deeper reasoning (rationales for feasibility and desirability) and an approach to creation (iteration, experiments). This is beyond the capabilities of such systems at the moment, and it’s unclear if the current tech will ever be able to do this. Even if Figma collects ten thousand years’ worth of UI design, the reasoning remains outside its bounds.

The other 30% is also interesting. Getting software til production goes beyond pretty UI design. Larger and more mature products will need experienced designers more than ever to untangle complexity, it’s just unclear where that experience comes from if AI tools cannibalize junior roles.

The above problem together with the current market trends (laying off a bunch of designers and researchers, especially from more strategic roles) does mean, that we will get tons of unusable, soulless, money-grabbing apps until at least the next vibe shift.

Something I stress to my teams is that the questions asked of us as researchers are often tightly scoped to what’s top of mind for our cross-functional partners and stakeholders. Sure, answering these questions at face value will help us with today’s decisions and will likely earn us positive peer reviews, but at enormous opportunity cost. We instead should provide helpful answers while also illuminating the next larger context. This is how research findings shift from disposable to durable.

Researchers — or more generally people doing research — tend to be curious bunch, so more juniors tend to make the mistake of focusing research on learning anything, that in turn makes the research directionless, results vague, rarely having an impact on design or product decisions. So the answer is clear, make sure each study is clearly focused on answering one or few large questions. Every detail (like participants, method, or guide) needs to be focused on answering that one question, so making an unknown detail known.

The problem with this approach is what the above article points out: we strip the possibility of learning truly new information, so unknown unknowns. So the solution is to set the research questions, and then broaden the scope, peeking overt the edges on what else is there besides our immediate focus.

Where things get really interesting is when we look besides one study and try to build a research system. Collecting questions and answers into a repository is helpful, but rarely leads to new insights. But having information on unknown unknowns laid out enables people to learn new things from existing studies.

…most Product teams (and executives) want you to deliver visual screens and prototypes as quickly as possible. This is why companies like Figma market “Generate a design” based on AI prompts to Product Managers, and Product Managers gaslight you into working faster: they want fast visual results. Most teams don’t realize that this results in “Fast + Cheap” Designs, which are a waste of time. Learning to push back and show restraint with visuals gives you enough time to create “Good + Fast” work instead.

and

to obtain what you need to do the job correctly, you need to restrict access to your visuals. When you say, “I need to learn more about X to generate the mockup,” your Manager might listen and quickly get you access to those resources. However, if you ask that same question but you’ve handed over your prototype, you often might get a vague answer and pushed to the back burner.

Share early and often is still right, but the right things need to be shared at the right time to move the process forward. Exercising restraint also helps in collaboration as it opens up to feedback and invites input. It’s a balance with design provocation (sharing visuals about a new direction early).