CAREER ANSWERS
Career Action Plan Template and Worked Example

THE SHORT ANSWER
A career action plan connects a target role to work you can finish, evidence you can inspect, and a date to decide what happens next. Choose one direction, set a realistic weekly time budget, and include a small market check and feedback request. Use the blank template below, then compare the two-hour and eight-hour examples.

Start with the goal and the constraint
This template is for an individual exploring a career change, preparing for a promotion, or building evidence for a target role. It works best when you have a direction to test and need to decide what to do this week. If the direction is unclear, make the first action a comparison rather than a course.
Write a target direction, the reason it matters, and the time you can reliably protect this week. Include an application deadline, an income requirement, location or schedule limits, and a spending limit when they affect the decision. You can keep private financial details in your own notes.
List the evidence you already have and the biggest unresolved question. You may need to establish fit, practice a task, explain existing experience or verify a qualification. The next action should address that specific need.
Keep later ideas in a separate note. They do not all need to become this week’s commitments. For a longer plan, set a four-week review date and choose the next week’s work after reviewing the current output.
Copy the career action plan template
Copy these fields into a note or document. Fill in the context first, then give each action a time budget, an output and a review point. The worksheet is available here without signing up.
Replace “improve my skills” with something observable, such as “draft a one-page account of the scheduling problem I solved” or “complete a fictional practice schedule with dependencies.” Use an existing piece of work when it can answer the question; check that you may share it.
Keep one main evidence-building task. A short market check tests whether that task relates to the role. A feedback request helps expose a specific weakness. These can all support the same goal within one weekly budget.
An output can be a work sample, a comparison table, an answer from an official source or a clearly stated decision. Set the review date before you start. Separate the evidence you intend to collect from the evidence you actually obtain.
Find existing experience you can use as evidence
Decide whether you need practice, proof or a credential check
Swipe or scroll horizontally to see every column. Keyboard: focus the table and use the arrow keys.
| Field | Your notes |
|---|---|
| Direction and reason | [Role, promotion or work direction; why you want to test it] |
| Current evidence and main question | [What you can already show; what is still uncertain] |
| Constraints | [Weekly hours; spending limit; schedule or location needs; deadline; other must-keeps] |
| Wider review | [Date to reconsider the direction; evidence that could change your decision] |
Swipe or scroll horizontally to see every column. Keyboard: focus the table and use the arrow keys.
| Action and purpose | Time and work slot | Visible output | Evidence or feedback obtained | Review and next decision |
|---|---|---|---|---|
| [Build one piece of role-relevant evidence] | [Minutes; day and time] | [Artifact or accurate account] | [Fill after doing the work; note limits] | [Date; continue, revise, pause or change] |
| [Test one role requirement or constraint] | [Minutes; day and time] | [Posting/source log or verified answer] | [URL, date and finding; unknowns] | [What would change the task or goal?] |
| [Ask one focused feedback question] | [Minutes; day and time] | [Request; response if received] | [Reviewer and scope; or pending] | [Interim action if no reply] |
| [Review this week’s results] | [Minutes; day and time] | [Decision and next bounded action] | [What changed; what is untested] | [Next work slot and review date] |
Use a two hour or eight hour weekly plan
Fictional example: Jon is a product designer exploring design-systems work. He wants evidence that he can explain a reusable component and its tradeoffs. He can use an original example, so he does not need to share his employer’s files. All postings, observations and outcomes in this example are invented to show the method; they are not research about current hiring demand.
Jon’s four-week question is whether design-systems responsibilities fit his interests and constraints well enough to pursue. This week’s question is narrower: can he explain one button component clearly enough for another designer to understand when and how to use it? His budget is either two or eight hours, with no paid course or software purchase.
Both schedules below cover evidence, a market check, a feedback action and a review. The extra time allows a deeper sample and more checking. Waiting for a reply does not count as working time, and a response is never assumed.
Swipe or scroll horizontally to see every column. Keyboard: focus the table and use the arrow keys.
| Work | 2 hours total | 8 hours total |
|---|---|---|
| Market check | 15 min: compare the task with one or two selected postings; note constraints | 60 min: compare a few relevant postings and narrow the sample brief |
| Build evidence | 65 min: write a one-page component note and a simple state sketch | 270 min: build a small sample, check it against the brief, and document choices and untested behavior |
| Feedback action | 20 min: prepare/send one focused request and self-review if no reply is available | 90 min: prepare a request; use available feedback for revision, or self-review and log external feedback as pending |
| Review and decision | 20 min: inspect the output and choose next week’s action | 60 min: inspect the sample, evidence and constraints; choose whether to revise, extend or pause |
| Total working time | 120 minutes; Tuesday and Saturday, 60 minutes each | 480 minutes; for example, two 2-hour blocks and one 4-hour block |
Read a completed career action plan example
Here is Jon’s completed two-hour version. His work slots are Tuesday 18:30 to 19:30 and Saturday 10:00 to 11:00. His review is Saturday at 10:40. He keeps his current job and work schedule while testing this direction, and he records employer compensation and location details as unknown until verified.
His fictional market log contains two entries. Posting A asks for component documentation and collaboration with engineers. Posting B emphasizes implementing a component library in code. The second opening may need skills Jon has not demonstrated. These are invented requirement summaries; a reader should record actual employer URLs, dates and wording in their own log.
Jon writes this sample note: “For a fictional appointment-booking screen, the primary button confirms the chosen time. The secondary button lets the user go back without confirming. I describe default, disabled and loading states, including the text shown while a request is pending. I would use a link for ordinary navigation. I still need to specify what happens when confirmation fails and how the pattern behaves with keyboard and screen-reader use.”
This is a short design rationale, not an implemented or accessibility-validated component. Jon’s evidence is the note and his state sketch. He has not demonstrated production adoption, engineering implementation, or user outcomes.
During the feedback block, Jon sends an optional request to a designer he knows: “Could you look at this one-page component note? Which instruction would be hardest to apply, and what important state or tradeoff is missing? A short reply would help; no problem if you don’t have time.” He shares only his original example. At the review point, no reply has arrived.
Jon’s self-review finds a specific omission: the note mentions a failed confirmation but never explains the resulting state. His decision is to revise the same sample next week by adding that state and clearer usage guidance. External review remains pending, and he does not claim that the sample has been validated.
With an eight-hour budget, the corresponding output would be a small original component sample, documented checks and a short case study. That is a planned output, not a second completed result. Jon should record what he actually finishes, along with any untested behavior.
Check role requirements and ask a useful feedback question
Start with a small set of current, relevant employer postings. Save the employer, title, location, URL, date checked, one relevant responsibility and any stated constraint. Ask whether this week’s output helps demonstrate that responsibility. One or a few postings help scope a test; they cannot establish market demand or your chance of being hired.
For U.S. occupation background, O*NET describes skills, work activities and other occupational characteristics. The BLS Occupational Outlook Handbook describes typical duties, preparation, work environment, pay and outlook. Check the particular employer separately. An occupational median is not a prediction of your starting offer.
For a promotion, use the organization’s next-level rubric and a manager conversation as the requirement check. Ask which evidence would help establish the expected scope and which business or timing conditions are outside your control.
Give a reviewer the target responsibility, a short artifact and one focused question. Ask what is unclear, what is missing, or which claim goes beyond the evidence. A reviewer’s opinion is useful context; record who reviewed the work and what they actually assessed.
If no reviewer is available, review against the written brief and mark external feedback as pending. Choose an interim action you can complete yourself. Silence does not establish that the work is good or bad.
Review the output and choose what happens next
At the review point, record what you finished, the evidence or feedback obtained, and the most important unresolved question. Then choose continue, revise, pause or change direction. The completed review below shows how Jon separates an output from validation.
Continue when the output answers the current question and the next small test is clear. Revise when feedback or self-review identifies a specific weakness. Shrink the task if it exceeded the time budget. Pause when a necessary input or a hard requirement remains unresolved. Change direction when verified constraints make the goal unsuitable.
Do not wait until a four-week or ninety-day plan ends to use new information. Review at the end of each work block or week, and revisit the wider direction at the date you set. These are suggested planning intervals, not deadlines for getting hired.
Finishing a course is an activity; being able to use what you learned in the target task is a separate question. Carry forward the unanswered question and next test rather than an ever-growing list of unfinished tasks.
Swipe or scroll horizontally to see every column. Keyboard: focus the table and use the arrow keys.
| Review field | Completed entry |
|---|---|
| Evidence produced | One-page component note and state sketch; no working implementation |
| Market check | Two fictional requirement summaries; one documentation-focused, one implementation-heavy; compensation and location still unknown |
| Feedback | One request sent; no reply at the review point; no external validation |
| Observed gap | Failure state is mentioned but not explained; keyboard and screen-reader behavior remain untested |
| Decision | Revise the same sample; defer implementation-heavy applications until requirements and evidence are clearer |
| Next action | Tuesday 18:30 to 19:30: draft the failure state and usage guidance; Saturday 10:00 to 11:00: review against the brief and any reply received |
| Next review | Saturday 10:40: inspect the revision and record what remains uncertain; reconsider the wider direction at the four-week review |
Keep uncertainty and personal limits visible
A plan can help you allocate effort and notice new evidence. It cannot guarantee a promotion, an interview, a job offer or a reliable hiring timeline. The two-hour and eight-hour allocations are illustrative, and some tasks require longer blocks or specialist equipment.
Verify required licenses, qualifications and work-authorization conditions before spending on training or making a costly commitment. Use the responsible authority or employer for the specific requirement; general career guidance cannot settle individual legal or licensing questions.
Keep employer files, customer information and other people’s personal details out of public samples. Use original or permitted material and state what you personally contributed. A simulated task should be labeled as simulated.
If available time falls, reduce scope or pause. Protect necessary rest, caring responsibilities and paid work. When the problem needs employment, financial or health advice, use an appropriately qualified professional.
Sources and limits
The worksheets and fictional examples are Openlin editorial guidance, not validated hiring assessments. These sources describe occupations and preparation; verify the specific opening and any required credential separately.
Start with one next action
Put this week’s action and review date in your own notes. The preview is illustrative and does not create your plan. Openlin’s waitlist provides early access updates without confirming product access.
Prepare your goal, one example of relevant experience, a time budget and the main question you want to test. Keep the plan in your own notes and review the evidence before choosing the next action.
A starting note to adapt
My goal is [direction]. I have [relevant evidence] and [hours] this week. My main uncertainty is [question]. Help me plan one evidence-building task, a small requirement check and a feedback action, with a review date and a clear decision.