The Skills I’m Weakest At

I asked ChatGPT what my weakest skills were, expecting it to point to something technical.

Maybe visual design. Maybe programming depth. Maybe drawing, which I have only recently started thinking about learning properly. Maybe some gap in strategy or business knowledge.

The answer was less flattering because it was more ordinary.

Selling. Focus. Repetition. Proof.

I can keep learning almost indefinitely. I can move from design into code, from code into research, from research into infrastructure, from infrastructure into writing, and usually make enough progress to feel that the movement was justified.

What I am less good at is staying in one lane long enough for the work to accumulate into something obvious.

That is harder to admit because breadth is one of the things I value most about myself.

I studied audiovisual media and later interaction design. I have worked on websites, accessibility, cultural organizations, sustainability, AI tools, public Wi-Fi infrastructure, technical performance, research, and product ideas that sit somewhere between all of these.

That range is useful. I often notice connections that are missed when a project is divided too cleanly into design, development, communication, and operations. A website can look like a design task while the real problem is governance. A slow service can damage trust before anyone notices the technical cause. Accessibility problems often reveal deeper product problems. Content, infrastructure, visual hierarchy, and organizational behavior are rarely as separate as they look in a project plan.

I am good at seeing that.

I am also very good at finding the next interesting direction before the previous one has had time to mature.

I have built paid websites, but many of the projects I talk about most are self-directed. Green Filter began as a thesis project and grew into research, prototypes, surveys, interviews, AI concepts, and several possible product directions. WiFi.ee became a database, a map, a poster system, a technical stack, an infrastructure problem, and at times a recovery exercise after things broke. HAAM has gone through different versions of its site, positioning, services, headlines, domains, and ideas about what the company should be.

None of these projects are fake. They are real work, and some of them have taken years.

Still, when I look at them together, I can see a pattern. I am often strongest during the stage where the problem is open and there is room to define the system. I like research, framing, naming, prototyping, connecting different layers, and finding possibilities that were not obvious at the beginning.

The later stages are less natural to me.

Selling the same offer again. Following up with someone who did not reply. Tracking whether the work improved revenue, conversion, retention, task completion, support load, or another measurable outcome. Turning one successful project into a repeatable service. Keeping the offer stable long enough that people begin to associate me with it.

Those activities feel narrower. They are also where a career starts to become legible.

Most of my paid work has been websites. That is useful evidence because someone trusted me enough to pay, and the work had to function in the real world. At the same time, the more strategic work I want to be hired for is often demonstrated through self-led projects. I can show that I understand research, systems, accessibility, trust, AI, and product thinking. I have less proof that an organization paid me to apply all of that and then saw a clear result.

This creates an awkward gap.

I can explain what I am capable of. The portfolio does not always make the commercial outcome equally visible.

Part of this is because many of my projects are in culture, education, public-interest work, or small organizations where measurement is weak. A theatre website does not always come with a clean conversion funnel. A research project can have hundreds of participants and still be difficult to translate into revenue. Accessibility and performance improvements matter even when nobody has set up a dashboard to track them.

That is true, but it also gives me somewhere to hide.

I often start measuring too late. I think about the case study after the project rather than deciding in advance what should change and how I will know. I can document the process in detail while leaving the result vague.

The outcome then becomes something like “the new system is clearer, faster, and more accessible.”

That may be accurate. It is still weaker than showing how much faster, for whom, and what changed because of it.

I do the same thing with positioning.

Over the past year, I have considered UX designer, interaction designer, product designer, experience architect, creative technologist, consultant, and several versions of studio or founder language. Each term solves one problem and creates another.

“UX/UI” feels too narrow and sometimes too shallow for the work I want to do.

“Experience architect” feels closer to the way I think, but it also risks sounding vague or inflated.

“Interaction designer” is accurate, though many clients do not know what it means.

“Consultant” says almost nothing by itself.

I can spend a surprising amount of time refining these labels because the problem is real. The label affects who understands the work, who contacts me, and what they expect to buy.

It is also possible that I keep returning to the label because changing it feels easier than testing one offer repeatedly.

A clearer commercial identity would probably require leaving parts of myself out of the first sentence. I resist that. I want the sentence to contain accessibility, performance, trust, storytelling, technology, design, research, AI, and strategy because all of those genuinely matter to the way I work.

The result can become accurate and hard to remember.

There is a similar problem in how I use technology.

I can build more than many designers. I am comfortable working with web frameworks, databases, APIs, hosting, automation, content systems, and AI-assisted development. I have set up systems that are real enough to fail in real ways.

That does not mean my engineering depth is equal across all of those areas.

I can move quickly when the architecture is familiar or when AI helps me fill in the gaps. I am less proven in the less glamorous parts of software work: testing, security, migrations, observability, maintenance, incident response, and keeping a large codebase understandable to several people over time.

The speed of AI-assisted development can blur that distinction. It is easy to produce something that works and then treat the working result as proof that I understand the system deeply.

Sometimes I do. Sometimes I understand enough to get through the current problem.

Those are not the same thing.

My visual skills have a similar unevenness. I have a good eye and a background in audiovisual media. I can usually see when a layout feels generic, when the typography is weak, or when the visual language does not fit the message.

I do not have the concentrated craft of someone who has spent ten years on type, illustration, motion, or art direction. I sometimes compare myself with people who have, then treat the gap as evidence that I should learn another skill before presenting myself more confidently.

That may be useful if I genuinely want to become a specialist visual designer.

It may also be another delay.

The weaker skill is probably not drawing itself. The weaker skill is deciding which gap matters enough to deserve serious time.

I have many possible improvements available to me. I could study drawing, learn Figma more deeply, become more rigorous in frontend engineering, study sales, produce better case studies, learn financial modeling, build content more consistently, develop a clearer offer, or create a stronger visual identity.

All of them would help.

Doing all of them at once would probably preserve the current problem.

The most uncomfortable conclusion from this audit is that my weakest skills are not hidden. They show up in the shape of my work.

I start a lot.

I can carry complicated projects a long way.

I am less consistent at creating a commercial loop around them.

The loop is simple on paper: choose a problem, sell the work, measure the result, document it, ask for the next project, and improve the process.

I tend to make the problem more interesting before I make the loop more reliable.

That tendency has given me a broad and unusual set of skills. I do not want to lose it. I also do not want to keep using it as evidence that the next thing I need is more breadth.

There are things I genuinely need to learn. There always will be.

The harder work now is deciding which abilities I already have enough of, and what I am willing to repeat before it feels new again.

AI authorship note

This essay began with Kris Haamer asking ChatGPT to identify the skills where he appeared weakest, followed by several rounds of rewriting to remove generic AI writing patterns and make the argument more specific to his actual projects. AI supported the initial audit, drafting, editing, and implementation. Kris directed the argument, rejected the earlier versions, and made the decision to publish it.

Connected reading

• The Further You Go in UX, the Less It Looks Like UX
• Doing Meaningful Work When Most of It Goes Nowhere
• The Product Needs a Harness