Please message directly for paid speaking engagements or workshops. Thank you! 

Get your copy of From Fraud to Freedom here https://tinyurl.com/2p94tpwt

If you've ever felt like an impostor, doubting your own accomplishments, or secretly fearing that you don't truly belong where you are, then "From Fraud to Freedom" is a must-read. This research-informed book delves into the heart of impostor syndrome, a challenge that even high-achievers like Michelle Obama have experienced.

The book is your guide to pushing past self-doubt and embracing your achievements. I share insights, stories, and strategies to help you navigate the common yet often overlooked challenge of impostor syndrome. With a focus on solutions and practical advice, this book empowers you to build a healthier relationship with your doubt.

You'll learn that you're not alone in your feelings and discover that there are tangible ways to grow through impostor syndrome. As you turn the pages, you'll find the inspiration and tools you need to believe in your own greatness again and reasses your relationship with fear. 

Don't miss out on the opportunity to unlock your true potential and step into your well-deserved success. So, if you're ready to take the journey from fraud to freedom, get your copy and begin your transformation to empowerment today. 

‘From Fraud to Freedom’ Table of Contents 
0 - Introduction 
1 - Should We Talk about Impostor Syndrome?
2 - Myth Busters: Should You Fake It until You Make It?
3 - How Do I Let Go of Perfectionism?
4 - How Does Asking Questions Help with Impostor Syndrome?
5 - How Do I Become More Positive?
6 - How Can I See My Work as Successful?
7 - How Can I Embrace Compliments?
8 - How Does Race Impact Impostor Syndrome?
9 - Are Women More Prone to Impostor Syndrome?
10 - Does Being First (Generation) Make You a Fraud?
11 - How Can Managers Ease Impostor Syndrome in Their Reports? 
12 - What Can Company Culture Do to Help Impostor Syndrome?
13 - To Freedom


February 2020 I was in hairdressing school in Nairobi on a gap/growth year. I noticed myself stagnating so I borrowed my cousin's laptop, used a phone chip to give myself wifi to teach myself how to code, and applied to a Software Engineering bootcamp.

March 2020 I moved to Houston Texas where I had no connections but my two suitcases & a dream. I had to adjust to being back in America, a new state and city, buy a laptop, and learn a lot of new tech & curriculum for the bootcamp starting a few weeks later.

April 2020 I was homeless. I almost didn’t start the program because I didn't have wifi to connect on but I insisted with my Education Manager that I had to make the chance I took on myself worth it ASAP.

July 2020 I graduated my bootcamp all while my roommates had COVID and I was interviewing at several companies.

August 2020 I joined as growth product manager at Redfin.

August 2024 I become Chief of Staff at the Product Career Accelerator.

I'm the first person I know to do the things I've accomplished and always the only one from my background to be in the rooms I've been in.

Which is why I'm going all on on supporting first or only tech leaders grow despite their feelings of imposter syndrome to understand that being different than the people around you doesn't mean you're wrong to belong.

📔 If you’re a “first” or “only” tech leader, DM me CONFIDENT and I’ll send you details to join my 30‑Day Imposter Syndrome Lab founding cohort of short daily exercises designed to help first / only professionals stop saying no to themselves out of fear and lead their career with confidence. (20 feedback spots at $49; regular price $199).

Phyllis Njoroge 🤩

Imposter syndrome help for first or only professionals so you can lead your career with confidence

500 people bought copies of From Fraud to Freedom, my research-informed deep dive on imposter syndrome, helping professionals move their careers with more confidence! It's in paperback, ebook, and - as of this year - Audible audiobook form!

The #1 thing I learned from writing a book is few people actually read it. 

So I’m building a practical daily implementation process right into your inbox.

I’m opening a 30‑Day Imposter Syndrome Lab for "first" or "only" professionals:
- 30 days of short, practical emails
- Daily exercises you can learn between meetings and put into practice immediately
- Designed so you stop replaying every interaction and actually lead yourself with confidence

Normal price will be $199.
I’m opening 20 feedback spots at $49 while I refine it with real clients.

If you’re a first or only tech leader and want to be part of the founding cohort, DM me CONFIDENT and I’ll send you the details!

P.S. If you’ve already read From Fraud to Freedom and it helped you (500 of you!), an honest Amazon review makes a huge difference. Everyone reads the reviews before they buy, but very few people leave one. Please do, I’d be really grateful.

Imposter syndrome help for first or only tech leaders so you can lead your team with confidence

From Fraud to Freedom by Phyllis Njoroge - tactical imposter syndrome book for professionals

My last job before PM was restaurant hostess. 

My last job before PM was restaurant hostess. 

People continue to ask what degrees, verifications, courses, and tools they need to add before they can start applying for roles when applications don't require permission. It's a fear of rejection by not understanding callback rates are 1-5%!

Having or not having a PM role at the moment isn’t a vindication of your ability to be great in the role! 

It just says whether someone took a chance on you yet. 
 
It’s less about the endless accumulation of certifications (though those have their place) and more about learning and growing while building genuine relationships with people who can connect you to an opportunity. 

Or at least that’s what happened for me.

My last job before PM was restaurant hostess. 

My last job before PM was restaurant hostess. 

My last job before PM was restaurant hostess. 

Go after it if you know why you really want it.

And never assume you know what someone is capable of because of their current job title. 

Talent is distributed equally; opportunity is not.

📔 If you’re a “first” or “only” tech leader, DM me CONFIDENT and I’ll send you details to join my 30‑Day Imposter Syndrome Lab founding cohort of short daily exercises designed to help first / only tech leaders stop saying no to themselves out of fear and lead their team with confidence. (20 feedback spots at $49; regular price $199).

“It’ll be done in two days” is not a timeline. It’s a personality test.
I learned this the hard way.
I used to treat “two days” as literal.

Forty-eight hours.
Two business days.
By end of day Wednesday.
Ready to go, right?!

Then I realized: depending on who says it, “two days” can mean very different things.

For some people, it means:
- two uninterrupted days of deep work
- a near-final, launch-ready deliverable
- something you could share with leadership
- edge cases considered, not just the happy path
- decisions already made, not open questions
- “I’d be surprised if this changes much”

For others, it means:
- I’ll have thoughts on it in two days
- I’ll send something rough to get unblocked
- something that still needs direction
- not safe to circulate widely yet
- “this will change once we meet”

So assuming they mean the same thing is how teams miss deadlines and start to lose trust.
This is where imposter syndrome sneaks in.
People don’t want to seem pedantic.
So they interpret timelines based on their work style, not the speaker’s.
Then frustration shows up later, when it’s harder to fix.
The fix is better and more questions.

Fraud Fixes:
- When will you get this done by?
- What does done look like by then?
- Do you want to check-in/discuss along the way or I’ll just hear from you on x? (align on what can feel like micromanaging)

It takes a few minutes.
It saves days of frustration.
Imposter syndrome says: don’t ask “too much”; just adapt to be “collaborative.”
Product work says: clarify accountabillity early so no one has to guess!

Let me know in the comments: What’s a phrase you’ve learned not to take literally at work?
(Everyone has at least one.)

Clarify timelines and deliverables - Phyllis Njoroge 

Writing a PRD feels worse than meetings because it leaves proof. Most PMs don’t struggle with writing PRDs. They struggle with feeling judged by sharing them. Imposter syndrome shows up loudly when you are writing a PRD.
    
    Suddenly everything feels exposed.
    
    Your thinking.
    
    Your decisions.
    
    What you chose not to include.
    
    So you start overexplaining.
    
    Spending time investigating corner cases.
    
    Writing defensively instead of clearly.
    
    Not because you lack product sense.
    
    Because a PRD feels permanent and public. It looks like proof.
    
    PMs do not write perfect specs.
    
    They write *useful* ones.
    
    It is a snapshot of your current thinking, given the information you have today.
    
    If your PRD is “perfect”, you waited far too long to get input.
    
    It needs to be clear enough to align.
    
    Flexible enough to change.
    
    Focused enough to move work forward.
    
    If imposter syndrome creeps in while you are writing, that is usually a signal you are trying to sound correct instead of biasing to action.
    
    I’ve seen some very messy PRDs create the best products.
    
    I’ve also seen the prettiest PRDs amount to nothing.
    
    A useful PRD moves decisions forward.
    
    Let me know in the comments: What helps you get unstuck when writing a PRD?

PRDs feel like judgement and trigger imposter syndrome 

I saved $1 million by asking a person I had never spoken to for feedback on my spec. As a customer growth product manager, I was working on a major overhaul of my primary checkout flow. Imposter syndrome used to show up for me as avoiding feedback on specs.
    
    Not sharing the spec with the head of marketing would have been imposter syndrome disguised as ownership. 
    
    That it was better to look decisive than to look unfinished.
    
    It would have sounded like, “I don’t want to distract people yet” or “I’ll loop them in once it’s tighter.” 
    
    But the truth is, I didn’t want to be seen mid-thought by someone with real stakes. Avoiding a moment where someone important could see the seams in my thinking.
    
    At scale, that instinct is exactly how smart teams end up perfectly executing against outdated assumptions. It’s how work stays invisible until it’s too late to fix. 
    
    Asking for feedback wasn’t confidence. It was choosing exposure over comfort, and that exposure is what surfaced the risk before it became expensive.
    
    As a result, during this major overhaul of “my” funnel, I sent my WIP spec to a bunch of people for feedback. Even people I didn’t think would have any thoughts but I offered them the opportunity for feedback “just in case.”
    
    That’s how I learned a seven-figure marketing campaign was about to launch based on assumptions from an older version of the spec that I had never sent them (can specs go viral? 😂)
    
    This was my first time interacting with the head of marketing 
    
    His first time finding out about this overhaul
    
    My first time finding out about his New Year’s bet on my checkout flow 
    
    The checkout flow that I was about to entirely change.
    
    I shared a new spec with all department heads *just in case* they had thoughts.
    
    No formal dependency.
    
    No explicit handoff.
    
    Just a quick ask.
    
    A funnel they didn’t realize was changing, fast.
    
    A funnel I hadn’t realized they were relying on.
    
    Asking early saved a lot of time, money, and trust.
    
    The biggest risk wasn’t bad work.
    It was parallel work happening quietly in different corners of the company.
    
    Alignment doesn’t happen automatically just because teams are good.
    It happens because someone asks the necessary questions.
    
    The irony is that risking my credibility with a senior leader is exactly what created it.
    
    Let me know in the comments: What helps you decide who to loop in early?

Saved millions by asking questions and sharing widely

Betting on yourself is extremely triggering. 
Every time I take a step toward building the future I want, 
I'm floating between a mix of grief for how long I tolerated what I didn't deserve,
Fear thinking I'm a complete idiot for even trying,
Impatience because I don't know when it's actually going to work but I know that it has to,
Ego trying to remember I'm not better than anyone just because I got opportunities that they didn't,
Pride because I work hard AF to get here.

I'm betting on myself with this whole imposter syndrome thing because I know almost every one of you needs it, not matter how long it takes me to get the execution right.


📔 If you’re a “first” or “only” tech leader, DM me CONFIDENT and I’ll send you details to join my 30‑Day Imposter Syndrome Lab founding cohort of short daily exercises designed to help first / only professionals stop saying no to themselves out of fear and lead their career with confidence. (20 feedback spots at $49; regular price $199).

I thought writing a spec was plagiarism. But specs aren’t essays. They’re not graded on originality.
I used to think writing a spec meant coming up with something entirely original.
School trained me that way.
Using someone else’s idea was plagiarism.

So when I started writing specs, I felt pressure to invent.
New flows.
New frameworks.
My own words. My own ideas.
Not because that was better product work.
Because it felt safer.

If the idea was mine, no one could question my value.
That’s how imposter syndrome showed up.

Over time, I realized how backwards that thinking was.
In product work, not using a good idea just because it came from somewhere else is wasteful!

Good specs do three things well:
- pull proven ideas into the right context
- adapt them to real constraints
- make them scalable across the people building and supporting the product

The strongest PMs I know borrow aggressively:
- from past projects
- from other companies
- from designers, engineers, research, support
- from patterns that already work
And they don’t hide it.
They integrate it.
Borrow aggressively & attribute generously.

Crediting teammates doesn’t dilute your impact; it compounds trust since product work is collaborative by design.

Imposter syndrome says: “If it’s not yours, you don’t deserve credit.”
Product leadership says: “If it works, use it and make it better.”

Innovation isn’t in inventing from scratch.
It’s in knowing what to keep, what to adapt, and what to discard.

Let me know in the comments: How do you decide when to borrow vs reinvent?

📔 If you’re a “first” or “only” tech leader, DM me CONFIDENT and I’ll send you details to join my 30‑Day Imposter Syndrome Lab founding cohort of short daily exercises designed to help first / only professionals stop saying no to themselves out of fear and lead their career with confidence. (20 feedback spots at $49; regular price $199).

I revised the common STAR method for answering interview questions. 

⭐ STAR (situation-task-action-result) over indexes on the context without zooming in on the impact. 

Therefore, I came up with the SAIL framework instead (situation -> action -> impact -> learnings) to more closely align with what interviewers are looking for when they ask these behavioral questions.

⛵ 𝗦𝗶𝘁𝘂𝗮𝘁𝗶𝗼𝗻al context (briefly). No one needs to know the inner workings of your previous employers. They need to know that your actions there translate to good work here if they were to hire you.

⛵ 𝗔𝗰𝘁𝗶𝗼𝗻 you took. Don’t claim ownership over a team effort nor let your ownership get diluted by incorrectly using “we” on things that you specifically did.

⛵ 𝗜𝗺𝗽𝗮𝗰𝘁 of your actions, ideally in measured form but qualitative results work too. How do you know that what you did was worth anyone’s time and how do you know that it was the right action to take?

⛵ 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴𝘀 regardless of whether it was the right action or not, but especially if the outcome wasn’t what you expected. Demonstrate a growth mindset, reflection, and intentionality about your work.

Imposter syndrome is interesting because it assumes other people know what they're doing more than you do. 

This kind of thinking prevents you from coming up with your own things to push the industry forward since you're relying on someone else to be the expert when really their expertise is either borrowed or some thing they came up with themselves that helps.

I chose to come up with something myself that I found more helpful. Let me know what you think of SAIL

📔 If you’re a “first” or “only” tech leader, DM me CONFIDENT and I’ll send you details to join my 30‑Day Imposter Syndrome Lab founding cohort of short daily exercises designed to help first / only professionals stop saying no to themselves out of fear and lead their career with confidence. (20 feedback spots at $49; regular price $199).

“That’s all you did?”
That’s the last thing you want to hear after you surface from heads-down dirty data digging.
You might have made real foundational progress that other people quietly rely on for years to come. Instead, it can feel like proof that you’re slow.
You tell yourself real PMs ship. Real PMs move metrics. Real PMs don’t spend days chasing context.
That’s imposter syndrome pushing you to chase heroics just to feel legitimate.
But there are no small projects.
Not in a feel-good way. In a “this prevents us from building the wrong thing” way.
We celebrate when something is right, but we rarely celebrate the work that prevented a wrong decision.
In product, some of the highest leverage work looks like nothing at first:
untangling messy assumptions
documenting how something actually works beforehand
asking “who else might this affect?” before anyone else does

Fraud Fixes:
- Pressure-test the “small project” label. Ask who might reuse this context later.
- Track decision impact, not just metric impact. Write down what decisions your work enabled or prevented.
- Do a 10-minute artifact handoff. Share notes or data with adjacent teams. If it’s truly small, it won’t help anyone. If it is helpful, you’ll know quickly.

Let me know in the comments: What’s an example of unsexy product work you’ve seen compound into major leverage?

Value foundational work Phyllis Njoroge 

Being a “well-rounded” PM is probably making yourself less hireable.
Great product managers aren’t evenly balanced.

We’re spiky!

Exceptional in a few areas.
Solid enough in the rest to collaborate effectively.
A lot of imposter syndrome comes from chasing the fantasy of the “complete” PM.
Exceptional at strategy, execution, analytics, UX, technical depth, stakeholder management, growth, tooling, AI, discovery… all at once.
That PM doesn’t exist. And if they did, they wouldn’t be practical on a team.

Hiring managers aren’t looking for a jack of all trades.
They’re hiring to solve specific problems.
They’re looking for a scalpel
while you’re busy trying to become a well-rounded spork 😭

When hiring managers look for PMs, they’re not grading you across every dimension.
They need someone whose spikes
match the problems they’re trying to solve right now.
Plus, anyone who believes they’re excellent at everything is usually overestimating at least one area.

The strongest PMs know exactly where they’re sharp, where they’re serviceable, and where they lean on the strengths of collaborative partners.
Imposter syndrome tells you that gaps mean you don’t belong.
Product work says gaps are intentional AND inevitable.

Fraud Fix:
The goal isn’t to be excellent at everything.
It’s to be exceptional at what the team actually NEEDS.
Let me know in the comments: Where are you intentionally spiky as a PM?

Spiky PM > well rounded product manager - Phyllis Njoroge

When I first became a PM, things used to be different. Onboarding earlier in my career, I asked everything back then. Everyone seemed friendly and ready to answer questions without judgment.
And over time, as the role got more real and expectations got heavier, that comfort quietly disappeared.
I started acting like asking was a tax on my credibility.

That’s how imposter syndrome actually shows up.
It looks like skipping further explanation instead of pausing to invite alignment.
Like assuming clarity instead of confirming it because I don’t want to seem like the only one who doesn’t know.
The irony is that the work only gets better when I do the opposite.

When I slow down to be intentional.
When I name things plainly.
When I ask many questions about the why, instead of defaulting to yes to seem “collaborative.”

Fraud Fixes
- Add one explicit “check for understanding” moment per meeting.
- Treat silence as a signal, not alignment. If no one reacts, instead of assuming no concerns, assume they’re just not being said yet and create an environment where people feel safe to express theirs.
- Write specs with a “Assumptions” section.
- If it feels obvious, list it anyway. That’s usually where misalignment hides.
- Force yourself to ask one “why” before defaulting to agreeing.
- Translate jargon out loud. If you used an acronym, restate it in plain language once.

Imposter syndrome tells you to minimize yourself so you don’t look inexperienced.
Product work asks you to maximize alignment so everyone can do their jobs well.
Those are very different instincts.
And the moment I notice which one I’m following, I usually know what to fix.
Let me know in the comments: How do you personally signal that questions are welcome on your team?

📔 If you’re a “first” or “only” tech leader, DM me CONFIDENT and I’ll send you details to join my 30‑Day Imposter Syndrome Lab founding cohort of short daily exercises designed to help first / only tech leaders stop saying no to themselves out of fear and lead their team with confidence. (20 feedback spots at $49; regular price $199).

Imposter syndrome help for first or only tech leaders so you can lead your career with confidence

Ask more questions, like you did earlier in your career 

Dear PMs,
    
    You’re not a designer.
    
    Imposter syndrome as a PM shows up as over-involvement.
    
    Over-specifying.
    
    Pre-solving the UI so no one questions your contribution.
    
    Your desire to take over and make a slick looking interface is redundant and disempowering to someone who’s spent a career learning the deep craft that is product design.
    
    You don’t want to walk into the review with only a problem statement and questions.
    
    You feel like your work needs to be something tangible. 
    
    You want something to point to and say, “I contributed.”
    
    But these behaviors are not collaboration.
    
    Give your design partner creative freedom, rather than just contracting them to make a high-fidelity version of your own vision.
    
    Over-stepping into design work is often less about product intuition and more about imposter syndrome of being replaceable.
    
    You’re worried that if you don’t bring a solution, you’ll look like you’re not doing your job of owning and leading the product. 
    
    You can ground the work in business goals and user problems.
    
    You can bring research and analytics to the table.
    
    Bounce ideas and riff off each other in a way that feels fun.
    
    Then you can give your design partner real creative freedom instead of asking them to execute your pre-baked vision.
    
    I’ve worked very closely with design to a degree that other people have asked me “where’s the line between you and design?” 
    
    Each person has their own philosophy on how they work with design 
    
    but mine is that there isn’t a strong line when it comes to improving the user experience.
    
    We’ll share research and analytics context, iterate solutions together, and decide next steps together. I have lost nothing by getting design more, not less, involved.
    
    Let me know in the comments: What practice has improved your partnership with design the most?

I hated writing my imposter syndrome book. It swallowed my evenings and weekends when I was already spending all day working as a customer growth product manager. 

I didn't write a book because I enjoyed the process. I wrote it because it felt extremely necessary. Given my experience with imposter syndrome, especially as a product manager. The existing literature didn't really address how it intersects with identity, which is why I wrote chapters on navigating it while 
- first gen, 
- female, 
- or as a person of color.

I followed this up last year by publishing a deeper dive workbook called Impostor Syndrome While Black. 

This year, I’m continuing that work: filling the gap for practical imposter syndrome guidance that understands how systemic oppression and toxic corporate culture breed imposter syndrome, then gaslight you to “just be more confident.”

I’m running a 30‑Day Imposter Syndrome Lab for “first" / "only” tech leaders:
30 days of short, practical exercises to help you stop saying no to yourself out of fear and actually lead your team with confidence.

If you’re a “first” or “only” tech leader and want to be part of the founding feedback cohort (20 spots at $49; regular price $199), DM me and I’ll send you the details.

I like to find the most senior person in the department and ask them 
"how hard is this for you to do?" Why do I do this?
Imposter syndrome has this interesting way of making us feel incompetent when some things are just hard. 

I built a great working relationship with our director of analytics and during our 1:1s, I'd talk to him about something I was struggling with as an IC PM.
He'd calibrate me on the fact that even he doesn't know how to find the thing I'm looking for so I wasn't stupid, I was just working on a challenging problem.
 
At the time, we were running very lean on data scientists, even pre-layoffs, so I was forcing myself to find answers that were allegedly delegateable (is that a word?) but would that would turn into a self-doubt spiral getting down on myself about not being the perfect "data-driven" PM.

I'm eternally grateful for those 1:1s with our director bringing me back down to earth!

Fraud Fix:
- Who are you treating like an all-knowing wizard who you'd discover up close also struggles with the same problems that you do?

Let me know in the comments: what's something that felt like it was personally hard until you discovered it's generally challenging regardless of level of experience?

📔 If you’re a “first” or “only” tech leader, DM me CONFIDENT and I’ll send you details to join my 30‑Day Imposter Syndrome Lab founding cohort of short daily exercises designed to help first / only tech leaders stop saying no to themselves out of fear and lead their team with confidence. (20 feedback spots at $49; regular price $199).

Talking about hobbies makes my product work better.
I’d meet with developers regularly before I needed anything.
Quick intro chats.
Asking how they liked to work.
Sharing half-formed ideas instead of polished specs.
No agenda beyond: we’re going to be in this together.

What surprised me was how fast the returns compounded.
Developers flagged risks earlier.
Assumptions got corrected cheaply.
Tradeoffs were surfaced without defensiveness.
Feedback felt collaborative instead of reactive.

Early relationship-building isn’t “soft stuff.”
It creates trust before disagreement.
Context before conflict.
Psychological safety before execution.

Fraud Fixes:
I meet with everyone before we have a shared project to necessitate a meeting
I ask how they like to work
I treat questions as contribution, not friction
I invest time with my closest partners when nothing is on fire
Imposter syndrome tells PMs to wait until they’re useful. Product leadership understands usefulness compounds with trust.

Let me know in the comments: What’s something you intentionally invest in early to make execution smoother later?

We know what this industry looked like ten years ago. 

Even five years ago. 

Let alone twenty years ago.

And that pool is what you’re requiring your ideal candidates to be. 

Same with schools, 

degrees, 

and company names. 

You’re relying on a pool of people that have already been filtered by those schools’ and departments’ and companies’ biased rubrics multiple times over. 

Rubrics that are often biased and inequitable in present day despite "progress", let alone how inequitable they were ten plus years ago. 

I was hired into product management with no experience because my hiring manager evaluated for the skills necessary for the role at hand rather than blindly pattern matching things like a computer science degree, MBA, or years of experience when I had none.

If you want things to look different, you have to do something different.

Beyond asking everyone to pattern match what exclusionary success has historically looked like.

A spec should not be a surprise. If someone is seeing your spec for the first time when it’s “ready,” something broke upstream.

Product work doesn’t start at execution.
It starts at problem framing.

Your cross-functional partners shouldn’t just be recipients of decisions.
They should be participants in how those decisions are shaped.

When specs show up as surprises, teams react instead of collaborate.
You get:
- late-stage objections
- “we didn’t know this was changing” conversations
- rework that feels political instead of productive

None of that is a people problem.
It’s a process problem.
The best product work happens when partners are looped in from idea to execution.

When they understand:
- what problem you’re solving
- why it matters now
- what constraints you’re working within

Imposter syndrome says: “Don’t show this until it’s perfect.”
Product leadership says: “Don’t build this alone.”

By the time the spec is written, alignment should already exist.
The document isn’t the start of collaboration.
It’s the consequence of it.

If your spec feels surprising, the fix isn’t better writing.
It’s earlier partnership.

Let me know in the comments: How do you keep collaborative partners aligned before you ever type docs.new?

taplio

Phyllis Njoroge's Linkedin Analytics

Phyllis Njoroge

Performance ScorePhyllis Njoroge's LinkedIn Performance

What is Phyllis talking about?

Phyllis Njoroge's Best Posts (last 30 days)

Ready to grow your LinkedIn presence?