Interviewing is hard, and you're competing against people just as talented as you. Managers don't just compare skills when evaluating candidates; they also look to see which candidate is less risky. In this issue, you'll see how managers determine that risk.

You'll also look at how to make documentation drive product growth and adoption by tying it to how adults learn.

Drive Product Adoption with Adult Learning Theory.

Docs are more than support. They play a crucial role in product adoption. Documentation is where technical practitioners go to see if your product is a good fit. The 2025 State of Docs survey indicated that 90% of respondents say documentation is important when making a purchasing decision.

The website is for buyers, but the documentation is for practitioners. The CTO or VP of Engineering may hear about a product, but they'll ask a staff engineer or other technical practitioner to do a deeper dive and make a recommendation. And those practitioners are busy. They won't have time to build a proof of concept with every product they evaluate. They're not going to talk to sales or hand over contact information for a trial. They're going to the docs. And they're looking for the "why" right away; they don't have time to sift through docs that just talk about features to figure out if those features solve problems.

Your docs need to focus on the solutions you offer, not your features. And you can do this by tapping into adult learning theory.

In Issue 19, you got an introduction to andragogy, a theory about how adults learn. Here are some key things to understand:

• Adults need to know why they need to learn something.
• Adults thrive in independent learning scenarios.
• Adults approach learning as problem-solving and need to learn experientially
• Adults learn best when the topic is of immediate value.
• Adults have prior experience they use as a baseline.
• Adults are motivated by internal factors rather than external pressures.

The motivation is the most important part here. If you make your product too hard for someone to understand, even at a basic level, they'll move on. This is why you need to answer the "what's in it for me" questions technical practitioners have:

• What problem does this solve?
• How will this make me better at my job?
• What will I be able to do that I couldn't before?

A lot of documentation is feature-focused, not problem-focused. It talks about the feature and its options or how you use it, but not why you would use it or when you would use it. And some documentation doesn't even think about the product holistically. It focuses on individual features but leaves the integration of those features up to the developer.

So one way to solve that is to look at a framework like Jobs-To-Be-Done (JTBD):

• Customers hire products to make progress in a specific context. The "job" is the actual unit of value.
• The goal is to build features that shorten, simplify, or de-risk the job
• Focus on outcomes and context rather than demographics or feature wishlists.
• Craft messaging around job success ("Get X done faster, with less hassle") instead of technical specs.

This framework directly solves the issue and lines up nicely with the theory of andragogy:

Andragogy assumption	JTBD parallel
Adults need to know why they need to learn something.	A job always begins with a struggling moment; the user must see the unmet outcome.
Adults thrive in independent learning scenarios.	Users "hire" or "fire" a solution; agency is central.
Adults have prior experience they use as a baseline.	Context is king: existing workflows shape the job.
Adults learn best when the topic is of immediate value.	Jobs surface at the moment of progress-seeking.
Adults approach learning as problem-solving	JTBD defines success as completing the desired outcome, not mastering features.
Adults are motivated by internal factors rather than external pressures.	Social/emotional forces (confidence, status) sit alongside functional goals.

Knowing this, you can start making changes to your content immediately.

• Start every topic with the concrete problem it helps the reader fix.
• Offer modular docs, self-serve pathways, and alternative formats.
• Acknowledge typical starting states; show shortcuts that build on what the user already has.
• Align tutorials and guides to common triggers. For example, use transitions between sections or topics like, "You've just deployed your app in production. Here's how to monitor it").
• Organize docs around outcomes rather than product areas. For example, "Send your first webhook.")
• Use examples that signal competence gains or peer recognition to keep momentum.

These things help discovery, but they also help activation and expansion. Each piece of contextualization you add to your documentation increases your chances of a new or existing customer discovering more ways they can use your product to solve problems.

Product documentation isn't just a support and retention function; it's a revenue driver. The more you invest in this, the more returns you'll see. Your documentation can be the tool that drives sales enablement and even top-of-funnel growth.

Things To Explore

• ocode is an Ollama-based coding assistant influenced by Claude Code.
• The new Have I Been Pwned site is live. Go check and see who stole your data.

Prove You Aren't Risky

Every hiring manager has been burned by someone who looked great on paper but couldn't execute when it mattered. They may have had the right skills but couldn't work effectively with other people or teams. Maybe they were great at communicating progress and status but lacked the deep technical skills they claimed on their resume. They could have delivered good work, but it took twice as long as expected.

If you got an interview with the hiring manager, they believe you can do the technical work. Now they have to dig deeper because hiring someone new is risky. When a hiring manager gets headcount approved for a role, they've made promises to their leadership about what that person will deliver. The manager's biggest fear is that you won't deliver the results they promised their boss.

They need to "de-risk" you.

What they look for to de-risk you

The hiring manager is evaluating two main risk categories: execution risk and collaboration risk.

Execution risk is about whether you can actually get the work done effectively. Do your technical skills translate into real-world problem-solving? Can you work independently without constant guidance? Do you understand business priorities, not just technical requirements? When you describe past projects, can you articulate the impact you made, not just the work you did?

Collaboration risk is how well you integrate with existing processes and people. Will you slow down other team members? Will you create friction that distracts from the work? Will you need more management attention than they can provide?

Here's what they look at to help them decide if you're the person to hire:

• Resume honesty and depth. When they dig into your technical claims, do your answers show real experience or just surface-level knowledge? If you listed "expert in distributed systems" but struggle to explain when you'd use CQRS over the Saga pattern, they'll wonder if you can handle the complex discussions and decisions their projects require. They need confidence that you've solved problems similar to theirs.

• Communication that drives results. Can you explain technical concepts to non-technical stakeholders clearly and concisely, or do you get into the weeds? How do you handle questions you don't know the answer to? Do you ask clarifying questions that show you understand business requirements? Your ability to communicate clearly directly impacts your ability to deliver what they actually need, not just what you think they need.

• Adaptability under real-world constraints. When they describe their current tech stack or development process, how do you respond? Do you immediately suggest they change everything, or do you show curiosity about their current environment? They may agree that things aren't ideal, but right now, they need someone who can improve things while working within existing constraints.

• Professional collaboration skills. How do you talk about previous employers, managers, and teammates? Your potential manager needs to know you can navigate workplace dynamics professionally. Communication and collaboration problems hurt project timelines much more often than technical problems.

Note: These are the legal things they can focus on to de-risk you. They can't consider you a risk if you have a disability, have children, or are over a certain age because those (and more) are protected classes in the US. They also can't discriminate against you even if you have a history of suing former employers, as that would be retaliation.

If they're spending time out of their day to speak with you, it's because they think you can do the job. Now's your chance to show them.

Show you drive results

Focus on demonstrating that you understand the business context behind technical work. When discussing past projects, emphasize outcomes and impact, not just the technical challenges you solved. Show that you can work within constraints and deliver incrementally rather than needing things to be the way you find the most comfortable.

Ask thoughtful questions about success metrics, current bottlenecks, and team goals. This shows you're thinking about results, not just interesting technical problems.

When answering questions, show how you drove results, but don't forget to explain how you worked with team members and other departments to get things done. Make it clear that you know how to get things done with others.

Be honest about your experience while showing how you'd approach their specific challenges. If you're comfortable with how they do things, give specific examples of things you're excited to deliver that align with the needs outlined in the job description. If you're unfamiliar with their tooling, say so and explain how what you can do will help you learn the new processes and contribute quickly. Either way, demonstrate to the hiring manager how you can solve their problems right away.

Remember that your online presence matters.

As I mentioned in Issue 40, everything you do professionally creates a permanent record, and some of that record is publicly available for everyone to see on LinkedIn, Reddit, and other online communities.

Many hiring managers are looking at your general online presence. They're not looking for your general opinions, but they are looking for patterns that predict how you'll behave in professional settings.

• Are you constantly picking fights online in comments sections?
• Do you share strong negative opinions about technologies your potential employer uses or the potential employer's product itself?
• Are you spending work time on unproductive debates instead of focusing on results?
• Are you interested in doing the work, or are you interested in building a personal brand for yourself?
• Are most of your posts complaints and grievances about the industry?

Social media gives hiring managers a glimpse into how you interact with other people. It can work for you or against you. It might not seem fair, but the manager's job is to hire someone who delivers results with minimal risk to them, their team, and the organization.

Remember, they want to hire you. They wouldn't have called you in otherwise. Your job is to make it easy for them to confidently tell their boss that you'll help deliver what was promised.

Parting Thoughts

Before next time, here are some things to think about:

1. Look at your company's current product documentation and pick a feature at random. How does it stack up? Does it give you clear ideas on when you would use the feature or why? Or does it just focus on how to make the feature work? What small changes can you make to the page to add more contextualization?
2. In Issue 7 you saw how to craft stories for your interview. Review those stories and write ones for yourself using what you saw in this issue to demonstrate you're not a risk.

Thanks for reading!

I'd love to talk with you about this newsletter on Mastodon, Twitter, or LinkedIn. Let's connect!

Please support this newsletter and my work by encouraging others to subscribe or by buying a friend a copy of Exercises for Programmers, Small, Sharp Software Tools, or any of my other books.