Positioning yourself may be the hardest positioning job

Positioning a product is hard, and any competent marketing strategist knows that. Positioning yourself is harder, because you are simultaneously the strategist, the product, the subject-matter expert, the customer, and the person who has to live with the answer. Here is what six weeks of doing it looked like.

TL;DR

• Positioning a product is hard. Any competent marketing strategist knows that.
• Positioning yourself as a professional can be harder because you're simultaneously the strategist, the product, the subject-matter expert, the customer, and the person who has to live with the answer.
• I'd already done a substantial amount of work positioning myself before I started rebuilding my website. I had built career-engine and the career-data system behind it for my own job search, professional materials, and applications. The mistake was assuming that work could simply become the positioning for a different context.
• It couldn't.
• Over six weeks, I ran a separate positioning exercise for the website, then rebuilt the site around it. Along the way, I repeatedly stopped the build to research better options for messaging, content, information architecture, visual design, functionality, accessibility, and platforms.
• I used Claude Code, Claude Design, Figma, Webflow, Astro, and Framer.
• The tools sped up the work.
• They didn't make the decisions.

You know positioning is hard. You forget what it feels like when you're the product.

I'm a marketing strategist, and I know positioning is usually where the difficult work lies. However, the most interesting part was discovering what changes when the product being positioned is yourself. A company gives you some useful distance: you can interview customers, study competitors, argue with the founder, and examine the product as something that exists outside your own identity. You don't get that distance with yourself. You know every version of the story, remember why you made a decision five years ago, and know which jobs you had, which ones you loved, and which parts of your experience you're proud of. You also know exactly how flattering a particular description can sound.

That makes professional self-positioning a meta experience: you're using positioning to decide how to position the person doing the positioning. And there is one more complication: your professional self isn't a single product with a single use case. You can be selling consulting work, looking for employment, publishing ideas, mentoring people, speaking at an event, or trying to explain your career to someone who has never met you. While the same underlying positioning can support all of those things, the expression needs to change, and that is where I started to get into trouble.

I thought I already had the positioning. I was wrong about what that meant.

I hadn't started this project from scratch. I'd already built career-engine, the Claude Code and Cowork plugin I use for my own career work. That work included a substantial exercise in positioning myself as a professional, along with career-data, which holds the positioning framework, career content, and approved voice used across applications and other career materials.

That work was already a meta exercise. I was using marketing thinking to position myself as a professional, then building a system that could apply that positioning across CVs, cover letters, LinkedIn, and applications. So when I started the website rebuild, I wasn't thinking, “Now I need to figure out my positioning.” I'd already done that work.

I thought the next step was to give Claude the existing material and have it derive the website version. That seemed reasonable because the source material was there, the positioning had already been worked through, and the website was simply another expression of the same person. What I hadn't fully accounted for was the difference between having a positioning system and having decided what this particular expression of it needs to say. The career work had been built around applications, professional materials, and candidacy, whereas the website had different audiences, different jobs to do, and a different relationship with the person reading it.

The first website draft made that visible. Its H1 was pulled directly from the career positioning. The line itself was accurate, but the problem was that I had stopped making website-specific choices and assumed the model would make them for me. It couldn't. So I started a separate positioning exercise for the site. That became the cheyfitz.me Positioning & Messaging brief, which eventually brought together the career material, website work, Astro work, Notion, model sites, visitor-behavior research, and the design system, and then I had to actually do the work.

I was deliberately willing to jump into the deep end

There was another reason I let the early process stay loose: I was a one-person operation. Nobody was sitting there waiting for a deliverable from me, and nobody's work was blocked because I changed my mind about a headline. I could rebuild something myself, throw away a page, change the CMS, or switch platforms.

So I went in with three assumptions:

• Whatever Claude did, I could change later.
• It was better to start building and learn than spend weeks planning every decision in advance.
• I knew there would be LLM-specific behavior I would need to learn to manage, even though I didn't yet know what all of it would look like.

Those assumptions were useful, but they were also responsible for some of the mess. The first one meant I tolerated rough or frustrating output for too long; the second meant I learned requirements by building against them instead of predicting all of them; and the third meant I was discovering a new class of problems while simultaneously trying to finish the website. I don't think the answer is “plan everything first”. I still think getting into the work early was the right choice. The lesson is that you need to know which assumptions you're making when you choose that route.

The copy process itself became part of the problem

The agent was supposed to produce the actual copy. That was the assignment. I worked through the copy with it in long, frustrating conversations where there were outright arguments: I rejected line after line, questioned claims, and pushed back on reasoning. At one point, I stopped reading what it was giving me. That wasn't because I had decided the copy didn't matter; it was because I was exhausted by the interaction and still operating under the assumption that the model was listening to me and incorporating what I had already told it.

That's an important distinction. I hadn't broken one of my own rules; I had allowed myself to stop supervising closely because I believed the system understood the current instructions. That assumption turned out to be expensive. Once AI is generating inside the same working environment where you are making decisions, its output becomes part of the material you have to manage.

A bad prompt can introduce a bad assumption, which can become a design decision, then a rule, and finally show up in a later session as though it were established doctrine. At that point you're no longer just editing copy. You're cleaning up accumulated state.

The existing positioning was the inventory. The website needed a selection.

The draft homepage used a line from my job-search positioning:

The deep-tech category-positioning lead, the marketing executive who turns un-marketable technology into a defensible market position before the cash runs out.

It was accurate and well written, but it was also written for a different job. The source document was built for CVs, cover letters, LinkedIn, and recruiter conversations, whereas the website had to work for consulting clients, hiring managers, practitioners reading my work, and people I mentor. I only understood the distinction once I asked a very basic question: Where did that framing come from? The answer was a file, which made the problem much easier to see.

The file itself contained the principle I'd violated:

The framework is the inventory; every outbound artifact is a curated subset.

That's a useful way to think about professional positioning generally. Your positioning system is the inventory, while your website, CV, LinkedIn profile, and recruiter story are distinct expressions of it. The mistake isn't using the same underlying positioning. It's assuming every audience needs the same selection.

The problem wasn't “what do I do?” It was “what am I for?”

My old site had a long list of things I could do:

• Marketing strategy
• Content
• Technical writing
• Product marketing
• Mentoring
• Positioning
• Work across consumer products, operational software, and deep tech

That tells someone about my range, but it doesn't give them much help deciding why they should come to me. “Beard cream to deep tech” was memorable and answered “what have you worked on?” much better than “what are you uniquely for?” The site also had to work for several distinct audiences simultaneously:

A candidacy-oriented homepage worked for one group and created the wrong frame for the others. So the website needed a site-native position, which eventually became: “I take a product to market end to end, from its guts to its market story, and make it sell.” The range didn't disappear; it simply moved into the architecture, services, proof, and audience pages.

Self-positioning is a meta exercise

This was the part I hadn't fully appreciated before doing it: you aren't simply applying a positioning framework to yourself; you're observing yourself applying the framework. That creates some strange loops. I had to decide what my value proposition was, whether the language I used to express it sounded like me, whether that judgment was strategic or personal taste, and whether I was rejecting a line because it was wrong or because I didn't like seeing myself described that way. Those are fundamentally different problems.

One afternoon, I rejected six complete hero stacks, not because the meaning was problematic, but because of tone, rhythm, and syntax. Eventually I stopped generating headlines altogether and asked for the components underneath them: What's my value proposition? and What are my differentiators? I then wrote the final line from those components:

I take a product to market end to end, from its guts to its market story, and make it sell.

You need enough distance to judge the message, but you also need enough ownership to know when the message is technically correct yet still wrong.

And I had to reposition marketing itself

There was another layer to the exercise that I hadn't anticipated. I wasn't only positioning myself as a professional. I was also positioning myself as a marketing expert, which meant repeatedly asking myself what I actually think belongs under the word marketing. That turned out to be much harder than writing down a list of services.

I defined the service structure, built it, and then looked at it again and decided the definitions were wrong. I reorganized the services and service families at least four times after they already existed in the site itself: moving services between families, changing family names, adding services, removing others, and eventually expanding the model from four families to six. That wasn't cleanup; it was positioning work. Every time I changed the taxonomy, I was making a claim about what I think marketing is, where one discipline ends and another begins, and how the person buying the work is likely to think about it.

I kept finding the same problem: my first categorization was based too much on how marketers describe their own work and not enough on how the work actually gets bought, owned, and used inside organizations. Positioning might belong to product marketing in one company and to the founder in another, and a service can solve problems that cross several conventional marketing categories. So I stopped trying to make every service belong to exactly one neat box. The final model became six service families plus a second axis organized around role, allowing the same service to appear in more than one context because that's closer to how organizations actually distribute ownership.

This was probably the most useful part of the exercise for me as a marketer. I had to keep asking whether I was describing the market as it exists or merely repeating the taxonomy I had inherited from the profession. And because I'd already built the pages, I had to answer that question by changing a real site, which makes it much harder to hide behind a tidy framework.

Research became the way I created distance

Once I understood that the website needed its own positioning work, I stopped expecting the AI workflow to run straight from recommendation to implementation. I stopped, researched, compared alternatives, and then came back to make a decision.

• positioning and messaging
• visitor behavior
• information architecture
• visual design
• typography
• color and accessibility
• content structure
• CMS modeling
• platform capabilities and pricing
• mobile behavior
• interaction patterns
• buyer questions
• search demand

The workflow was closer to: Ask, research, compare, decide, build, test, revise. Sometimes the research took minutes, and sometimes it changed the direction of an entire section. At one point, an AI explanation used F-pattern research to support a headline choice; when I asked which research supported the claim, it couldn't provide any, and the rationale went away.

The same thing happened with visual work. Claude Design gave me a design direction, but I still researched and rejected visual patterns, changed typography, changed iconography, created another color system for the By Role pages, and checked accessibility at the token level. It happened with content too: the FAQ changed after I researched what people were actually asking instead of relying on invented questions, and the content model changed when I looked at what a useful Work Case needed to communicate. The research stops weren't interruptions to the build. They were part of the build.

Then I had to make the site agree with the positioning

Once the position was clearer, I had to make the rest of the site support it. That meant changing the information architecture: “Writing” became “Blog” and “Work” became “Portfolio.” Those labels aren't especially expressive, which is good. Navigation has one job, which is to help someone find the next page.

The service model changed too, eventually growing into six service families plus a second axis organized around roles because the same service can belong to different parts of an organization. Positioning might sit with product marketing in one company and with a founder in another, so a single taxonomy couldn't represent both cases cleanly.

The portfolio needed the same treatment. The old site had 25 pieces represented mainly by titles and images, but the new version turned them into Work Cases with detailed metadata including domain, industry and vertical, year, role, type of work, and brief. That changes the evidence available to a visitor: a title and image merely say “I made this,” whereas a Work Case gives a visitor a far better answer to “What problem did you work on, in what context, and what did you actually do?” That is positioning expressed through information architecture.

Image placeholder. Before-and-after comparison of one old portfolio card and the corresponding Work Case. Left: title plus image. Right: domain, year, role, brief, and work type. Caption: “Same piece. One record shows what I made. The other explains what I did.”

The tools were useful. The stops were more useful.

The stack is worth documenting because the project would have taken much longer without it.

The important part was the relationship between the tools and the decisions. I didn't let one recommendation become the next implementation automatically; instead, I used AI to generate candidates, explore structure, analyze material, write implementation code, and find problems. Then I went outside the AI workflow when I needed an answer it didn't have. That happened often enough that I now think of the process as a research loop with AI in it, rather than an AI build with occasional human review.

I changed platforms because the requirements changed

The platform sequence looked ridiculous: I used Astro, then built the site in Framer, and finally moved to Webflow. The first plan recommended Astro with Markdown and a Git CMS based on speed, cost, and ownership. I built it, then decided that those priorities weren't actually mine. I wanted a site I could run myself without designing the entire experience around developer workflows.

Framer came next, and I built the full site there. Then pricing and CMS limits exposed a more useful problem: I was treating my marketing site and my searchable tool directory as one product when they weren't. Once I separated the requirements, the platform decision became much easier.

My requirements included CMS needs, budget, integrations, ownership and maintenance, existing tools, comfort with code and GitHub, and the separate requirements of the marketing site versus the tool directory. The first platform review still got it wrong because I'd failed to specify one of those requirements clearly enough: the recommendation was wrong, but my input was incomplete. That is a much more useful lesson than “AI chose the wrong platform.”

AI became another thing I had to manage

The more AI sessions I ran, the more important this became. Rules started accumulating in files, and different sessions read different files where some decisions were current and some were obsolete. Sometimes an agent would tell me that something had to be done because “the rules say...” and I'd have to find the rule, work out where it came from, decide whether it was still current, and sometimes tell the agent that the rule was no longer the rule.

I had to keep track of where the current rule lived, why it existed, which decision created it, whether that decision was still current, and whether the rule applied to this part of the site. Eventually I had to make one hierarchy explicit: I'm the rule setter. An agent can recommend, implement, or remind me about a rule, but it doesn't get to become the authority that decides what the rules are. That sounds obvious, but with a long-running AI project, it isn't.

One of the most useful outcomes of the whole rebuild was learning to turn actual failures into explicit rules, then retire those rules when the underlying decision changed. The services rebuild that went wrong produced the CLAUDE.md STOP block; the copy problems produced the voice and fabrication guardrails. The project was teaching me how to manage the AI process at the same time I was using that process to build the site.

The site became the testing ground

Positioning didn't stop once the copy was written; the site became where I tested whether the positioning actually held together. The portfolio model, service architecture, and visitor paths were all tests, and then I found a gap that several audits had missed: product-market fit was missing as a visible service. It existed in my background, in earlier copy, and partly in the CMS, but a visitor couldn't find it. I fixed it by turning the existing ghost service into a real service rather than creating another CMS.

That distinction matters because an audit can find something that's broken, but using the site can reveal something that's missing. So I started using the site as though I knew nothing about it: I followed the navigation, tried to find services without knowing their internal names, looked for the evidence I'd need before contacting the person, read pages on a phone, and asked what I expected to find but couldn't. That last question is often the most useful one.

Launch QA is part of the positioning work

The day before launch, I opened the live URLs at a phone-sized viewport and found a three-column portfolio layout that overlapped, body copy below my own minimum size, a heading breaking in the middle of a word, an events calendar that needed a mobile agenda view, and filters with no matching data because the cards didn't expose the expected fields. A full live audit also found invisible text, sitemap 404s, orphaned pages, and a stale Google Fonts request. I also moved testimonials from a third-party widget into my own CMS and verified available avatars rather than filling missing ones with guesses.

None of that is positioning theory, but all of it affects whether the positioning survives contact with a real visitor. A visitor doesn't care which team owns the problem. A visitor experiences one website.

What I'd tell another strategist doing this

I wouldn't tell you to use my positioning, Webflow, or even AI. Instead, I'd tell you to treat professional self-positioning as a distinct kind of positioning engagement. Start with the same discipline you'd use for a business, then account for the fact that you're also the client. That means creating distance deliberately, separating evidence from preference, distinguishing the underlying positioning from its expressions, researching when the answer matters, letting the answer change when evidence changes, and being willing to throw away work that is technically good but strategically wrong.

You'll also need to watch for a few predictable traps:

• Your range will feel like your strongest proof, so you'll want to put all of it on the homepage.
• Old positioning work will feel reusable because you already paid for it with your time.
• Personal preferences will masquerade as strategy.
• A flattering statement will feel more persuasive because you know the person it's describing.
• AI recommendations will sometimes sound more certain than the evidence behind them.
• Old rules will continue influencing new work unless someone retires them.

That last group turned out to matter almost as much as the positioning itself.

Key takeaways

Nine things I'd carry into the next self-positioning project:

1. Treat professional self-positioning as its own kind of positioning problem. The product is a person with a career, history, preferences, and ego attached.
2. Create distance deliberately. Research, external evidence, and other people's reactions give you something to test your instincts against.
3. Keep the positioning system separate from its expressions. Your website, CV, LinkedIn profile, and recruiter story can all use the same underlying position without saying the same thing.
4. Don't confuse range with positioning. Range belongs in the architecture and proof. The hero needs a clear reason to care.
5. When copy won't settle, inspect the components. Ask for the value proposition and differentiators before asking for another headline.
6. Build research stops into the process. Check better options for messaging, content, visual design, functionality, and platform decisions instead of treating the first plausible answer as the answer.
7. Give AI a role, not authority. Let it generate, analyze, implement, and test. Keep the decisions yours.
8. Turn failures into rules, then retire rules when decisions change. You need one clear owner of the current system.
9. Use the finished site as a stranger. Audits find broken things. Visitors find missing things.

I still don't have conversion data for the new positioning, nor have I run buyer interviews or message testing against it, so I won't call it validated. This is a documented positioning exercise and site rebuild, not a proven market result. That distinction matters because a strategist should know the difference between a well-reasoned position and a position the market has actually confirmed.

The site is live, the positioning is a hypothesis, and the interesting part of the exercise was discovering what happens when the strategist has to position herself.

If you're in the middle of this for yourself or for a company, book a free 30-minute call and tell me what you're trying to position. No charge either way.