For new roles such as GTM engineering, revenue engineering or AI automation, verifiable work beats credentials because nothing on a certificate proves you solved a real problem. A credential says you studied a topic. Proof of work shows a situation, what you built, the result and evidence someone else can check. Credentials can still open a door, but proof is what lowers the risk for the person hiring you, and risk is what hiring decisions are really about.
This guide explains why that shift is happening, what the research does and does not say, what actually counts as proof, how MitHub verifies case studies, and how to present your own proof so it gets taken seriously.
In short
- New roles have no established degree, so employers look for evidence of the work itself.
- Employers say they value skills, but many have not changed how they hire. That gap rewards people whose proof is easy to check.
- Proof has levels. A claim is weak; a verified, paid result is strong. MitHub calls this the proof ladder.
- A strong proof artifact has four parts: situation, path, result, evidence.
- At MitHub a case study is published only after payment, delivery, audit, approval, client satisfaction and client consent.
Why credentials lose power in new roles
A credential is a proxy. It tells an employer that you probably have some knowledge, because a school or a platform checked you at some point. Proxies work reasonably well when a job is stable and the path into it is standardized: an accountant, a nurse, a civil engineer.
They work badly when the job is new. Nobody graduated in "GTM engineering" ten years ago. The tools change every few months. The work combines data, automation, AI and a commercial understanding of how a company makes money, which is exactly what we describe in what GTM engineering is. A course certificate in one tool says very little about whether you can connect that tool to a sales process and move a number.
So hiring managers for these roles face a problem: the usual proxy is missing or weak. They fall back on the most direct signal available, which is evidence that you already did a version of the work.
What the research actually says
It is easy to overstate this. "Degrees are dead" is not what the data shows. The more accurate picture has three parts.
1. Employers rely on work experience more than degrees
In the World Economic Forum's Future of Jobs Report 2025, employers were asked how they assess skills when hiring. Work experience was the most common method, with 81% of businesses expecting to keep relying on it over 2025–2030. Skills assessments came second at 48%, and a university degree requirement came third at 43%. The report notes that, compared with the previous edition, employers are leaning more on work experience and testing than on traditional credentials.
Work experience is, in the end, a form of proof of work. The question for anyone entering a new field is how to produce that evidence before someone gives you the job title.
2. Skills-based approaches expand who can be considered
LinkedIn's Economic Graph Research Institute has modeled what happens when employers look at skills instead of prior job titles. In its March 2025 research note, a skills-based approach expanded global talent pools by 6.1x on average, and by 8.2x for AI roles. Its earlier Skills-First report reached a similar conclusion with different data.
Read that carefully: this is a model of how many people could qualify, not a measure of who actually got hired. It shows that skills are a wider door than titles. It does not show that employers walk through it.
3. Announcing skills-based hiring is not the same as doing it
This is the part most articles skip. The Burning Glass Institute and Harvard Business School studied companies that dropped degree requirements and found that sustained changes in hiring were rare. As HR Dive reported, the researchers estimated the shift affected fewer than 1 in 700 hires in 2023. About 45% of the companies that announced changes showed no meaningful difference in who they hired, while about 37% were classified as leaders that actually followed through.
Why would a company remove a degree filter and still hire the same people? One likely reason: removing a filter does not tell you what to look for instead. If a hiring manager cannot quickly evaluate a candidate without a degree, they default to the familiar profile.
That is the opportunity. The talent who wins in skills-based hiring is not the one who simply lacks a degree. It is the one who makes their capability easy to verify.
Why proof of work lowers hiring risk
Think about the hire from the company's side. Every hire is a bet with three questions behind it:
- Can this person do the work?
- Can they do it in a context like ours?
- Will the work produce a result we care about?
A credential partially answers question one. It says nothing about two and three. A good proof artifact answers all three: it shows the work, the context it happened in and the result it produced.
This matters even more in the AI economy. When AI can execute a growing share of repetitive tasks (the premise of the new game), the value moves toward people who can decide what to build, direct AI and systems, and own the outcome. MitHub describes that shift with its capability ladder: Doer → Director → Designer → Owner (see director vs. doer). A certificate can show you learned to do something. Only proof can show you designed a system or owned a result.
What counts as proof (and what does not)
Not everything you can show is proof. Here is the distinction MitHub uses.
| Looks like proof | Why it is weak | Real proof |
|---|---|---|
| "Certified in Tool X" | Shows you finished a course, not that you applied it | A working workflow built in Tool X, with what it did |
| A screenshot of a dashboard | No context, no source, cannot be checked | The dashboard, its data source and the decision it changed |
| "Increased sales by 40%" | No baseline, no timeframe, no attribution | Baseline, period, what you changed, how it was measured |
| A list of tools on a CV | Familiarity is not capability | One system described end to end |
| A testimonial with no detail | Pleasant, not specific | A reference who can describe the problem and your role |
A useful test: could a skeptical stranger check this without talking to you? If not, it is a claim, not proof.
The MitHub proof ladder
Proof has levels. Knowing where your evidence sits tells you what to build next.
- Claim. "I know n8n." Nothing to inspect.
- Artifact. A workflow, a table, a script or a document that exists and can be opened.
- Applied artifact. The artifact solved a defined problem, even a practice one, and you can explain the situation and the decisions you made.
- Result. The artifact changed a number in a real context: time saved, leads enriched, response time reduced, meetings booked.
- Verified result. Someone other than you confirms the result: the client, a manager or an auditor.
- Repeated result. You produced verified results more than once, in different contexts. This is where people start treating you as an owner of outcomes, not an executor of tasks.
Most people applying for new roles stop at level 1 or 2. Moving even one level up makes you stand out. If you have no experience yet, start at level 3 with practice projects; our guide on how to build a portfolio without experience shows how.
The anatomy of a strong proof artifact
The sixth chapter of the Revenue Reverse Engineering faculty, your case study, structures proof in four parts. Use the same structure whether the project is paid or practice.
Situation
What was the context and the problem? Be specific about the business, not only the tool. "A multi-location business had leads waiting hours for a first contact" is a situation. "I wanted to learn Clay" is not.
Path
What did you decide and build, and why? This is where you show judgment. Following the method from follow the money, a strong path starts at the payment and traces backwards to where revenue was leaking before anything gets built.
Result
What changed, measured against a baseline, over a stated period? If the result is small, say so. A modest, honest result beats an inflated one that falls apart in the first interview question.
Evidence
What can someone else inspect? Workflow exports, before-and-after data, a recording of the system running, a reference, a client approval. Remove anything confidential; anonymize client names unless you have permission.
Here is how that framing sounds with a real MitHub reference point: MitHub's pioneers have built AI voice campaigns that ran across 28 live branches of a multi-location lending business, including a 10-branch pilot with 13,159 AI calls. Notice what that sentence does: it names the scale, the context and a countable output, without naming a client or inventing an outcome.
How MitHub verifies case studies
A portfolio full of unverified claims teaches employers to distrust portfolios. That is why MitHub does not publish a case study because someone says it happened. A case study is published on MitHub only after this sequence is complete:
- The company paid. The work had real economic value to someone.
- The talent delivered. The work was completed, not just started.
- MitHub audited the work. The work and its evidence were reviewed.
- It was approved.
- The company was satisfied.
- The client agreed to publish.
Each step closes a different gap. Payment separates real work from exercises. Delivery separates finished work from promises. The audit separates evidence from storytelling. Client satisfaction separates output from value. Consent protects the client and keeps the proof ethical.
The order matters too. Proof comes after value was created, never before. That is the same logic MitHub applies to its whole model: learn, build, prove, earn, in that order.
How to present your proof
Having proof is half the job. The other half is making it fast to evaluate. Hiring managers for new roles often do not have a checklist, so give them one.
Lead with the result, then show the path
Open each project with one line: the context, the result and the evidence type. For example: "For a practice project, I rebuilt a lead-routing process for a hypothetical 12-location clinic; the workflow export and a test run are linked." Details come after.
Match your proof to the job's real problem
Read the job description and ask what outcome the company is paying for. If they need faster lead response, your enrichment project matters less than your routing project. Put the most relevant proof first.
Label practice work honestly
"Practice project," "simulated data" and "personal system" are not weaknesses. Hiding them is. Honest labeling is itself a signal of the judgment employers are trying to hire.
Make the evidence inspectable in under five minutes
A short screen recording of the system running, a one-page write-up, and a link to the artifact. If a reviewer has to request access or schedule a call to understand it, most will not.
Show your level on the capability ladder
Say explicitly what you did: executed a task, directed AI to do it, designed the system, or owned the result. Overclaiming ownership is the fastest way to lose credibility in an interview.
Keep one proof page, not ten profiles
One place with your best two or three case studies beats scattered posts. On MitHub, talent profiles live at /talento.
Where credentials still help
Proof of work is not an argument against learning formally. Credentials still help in three situations:
- Regulated work. Licensed professions require them, full stop.
- Early filters. Some companies still screen by keywords and certificates before a human looks at proof.
- Structured foundations. A good program saves you from learning the fundamentals by trial and error.
The mistake is treating the credential as the finish line. Use learning to build capability, then turn capability into proof. That is why MitHub's foundations are free and each chapter of the Revenue Reverse Engineering faculty ends in one proof rather than a badge.
A 30-day plan to move up the proof ladder
For example, if you are starting from a claim-level CV:
- Week 1: Pick one business problem. Choose a revenue leak you understand, such as slow lead response or dirty CRM data. Write the situation in five sentences.
- Week 2: Build the smallest working system. One workflow, one enrichment table or one report. Record it running.
- Week 3: Measure. Define a baseline and a result, even on simulated or public data. Write down what did not work.
- Week 4: Package and get reviewed. Write the four-part case study, then ask someone experienced to try to break it. Fix what they find.
At the end you will have one level-3 artifact that most applicants do not have. Repeat with a real client, and you move toward verified results.
The bottom line
Credentials describe what you were taught. Proof describes what you can do for someone else. In new roles where no credential fully fits, employers lean on evidence of work, and the research shows that even companies that say they hire for skills often still struggle to evaluate it. Make your capability easy to check: a clear situation, a defensible path, an honest result and evidence a stranger can inspect. That is what turns learning into market value.
