Build a Notion Launch Portfolio

Create a public Notion case study for a simulated e-commerce checkout launch.

Introduction

30 Second Summary

Recruiters often meet your portfolio before they meet you. A list of project management skills cannot show how you respond when a launch slips or a stakeholder changes the scope.

In this project, you will build a public e-commerce checkout launch case study in Notion. Your page will show how your judgment develops from the baseline plan to a launch recovery decision.

What You'll Build

A recruiter can open one link and trace how your four-week checkout plan responds when a payment dependency arrives five business days late.

By the end of this project, you'll have:

A clearly labelled simulated capstone that shows recruiters how you would lead the fictional Northstar Market checkout launch.
A four-week launch baseline where a viewer can identify the scope, stakeholders, dependencies, and milestone owners at a glance.
A public At Risk recovery story that lets you explain the delayed payment integration, your guest-checkout scope decision, and the next checkpoint.
Secret Mission: Add a one-minute executive dashboard that communicates the business goal, project health, top risk, and next decision.

Are there any prerequisites?

You need a Windows device, an email address, and an internet connection. The guide includes checks for Microsoft Edge and helps you create a Notion account on the Free plan.

Before We Start

This project begins with a clear commitment to honest portfolio storytelling. You will present the checkout launch as a simulation that demonstrates your planning, communication, and change-management judgment without claiming professional experience.

Set Up Notion and Start the Portfolio

Your simulation commitment sets an honest boundary for this case study. The next challenge is giving that work a reliable home that a recruiter can open.

In this step, you will prepare Microsoft Edge for the project. You will create a personal Notion workspace with the first visible page of your portfolio.

In this step, get ready to:

Verify that Microsoft Edge can reach the Notion homepage.
Sign into or create a personal Notion workspace on the Free plan.
Create the portfolio page with a clear simulation label.

Verify Microsoft Edge

Notion fully supports Microsoft Edge for web access. Loading the homepage proves that your browser can reach the workspace tool.

Press the Windows key to open the Start menu.
Type Microsoft Edge into the Start menu search.

✔️ Microsoft Edge opens

Select Microsoft Edge from the search results.
Enter https://www.notion.com in the address bar.
Press Enter to load the page.

You'll see the Notion homepage in Microsoft Edge. That first browser check is complete.

ⓧ Microsoft Edge is unavailable

Visit the official Microsoft Edge download page.
Select Download Edge for Windows.
Open the installer from your browser's downloads area.
Follow the installer prompts to complete the installation.

You'll see Microsoft Edge become available in the Start menu when the installation is complete.

Press the Windows key to return to the Start menu.
Type Microsoft Edge and press Enter to open it.
Enter https://www.notion.com in the address bar.
Press Enter to load the page.

You'll see the Notion homepage load in your newly installed browser.

Notion homepage not loading?

Confirm that your Windows device has an internet connection.
Reload the Notion homepage in Microsoft Edge.
Run the downloaded Microsoft Edge installer again if the installation did not finish.

Help me troubleshoot why the Notion homepage will not load in Microsoft Edge.

Create your personal Notion workspace

A personal workspace keeps this capstone separate from future school or employer content. The Free plan provides everything this project needs.

Why Notion for this portfolio?

Separate planning tools can add setup that does not strengthen this capstone. Notion keeps the case-study narrative plus its simple tables in one workspace.

The Free plan supports web publishing. Your finished case study can become one shareable link.

Select Log in at the top right of the Notion homepage.

✔️ I already have an account

Enter your email address in the email field.
Complete the email-based sign-in flow.
Continue into the personal workspace associated with your own email address.

You'll see your personal Notion workspace. Your portfolio now has a private place to grow.

ⓧ I need to create an account

Select New user? Sign up.
Enter your email address in the email field.
Complete the email-based account flow.
Choose the personal-workspace option when Notion asks how you plan to use the workspace.
Select Free if a plan choice appears.

Your personal workspace is ready. You can now build the capstone without mixing it with school or employer content.

Having trouble signing in?

Check your email account's spam folder for the Notion message.
Confirm that the email address on the Notion page matches the account you can access.
Return to the Notion login page if the email flow expires.

Help me complete the Notion email sign-in flow safely.

Start the portfolio page

The page title gives your portfolio a clear front door. The simulation label tells every viewer that the scenario demonstrates your judgment without claiming professional results.

Select New page in the Notion sidebar.
Enter E-commerce Checkout Launch Case Study as the page title.

The foundation is visible now. Your case study has a named home in the workspace.

Select the empty content area beneath the page title.
Enter your name on the first content line.
Press Enter to create the next line.
Enter your target role on the next line. A suitable example is Technology Project Coordinator.

You'll see your name followed by the role you want this portfolio to support.

Press Enter below your target role.
Type Simulated Capstone Project directly below the introduction.

Before you review the finished page, which details should make the purpose of this portfolio clear to a recruiter?

Review the page from its title through the simulation label.

You'll see E-commerce Checkout Launch Case Study at the top. Your name plus target role appear above the line Simulated Capstone Project.

You now have an honest starting page that clearly separates simulated project work from professional experience.

Your workspace is ready for real project-management structure. Next up, you'll turn this starting page into a scoped checkout launch plan.

Build the Project Baseline

Your Notion page now labels the work as a simulation. It still needs a useful first version that shows how you would plan the checkout launch.

A project baseline records the agreed starting point before delivery changes begin. In this step, you will add the brief, scope boundaries, stakeholders, and milestones that make your plan easy to inspect.

In this step, get ready to:

Create the portfolio introduction with its project brief.
Define the launch scope with its stakeholder group.
Build the five-column milestone baseline.

Add the portfolio summary and project brief

A project brief connects the scenario to its business value. It also makes the assumed starting point distinct from the planned target.

Switch back to the E-commerce Checkout Launch Case Study page from earlier.
Click the empty line below Simulated Capstone Project.
Create a heading block by typing /h2.
Enter Portfolio Summary as the heading text.
Press Enter to start a new text block.
Enter I created this simulated capstone to demonstrate how I would manage an e-commerce checkout improvement from planning through launch readiness..

Your opening now tells a reader why the case study exists. That purpose frames every artifact below it.

Press Enter to create a new block.
Create another heading block by typing /h2.
Enter Project Brief as the heading text.
Add Company: Northstar Market (fictional). on a new line.
Add Problem assumption: Out of every 100 simulated checkout starts, 60 currently reach order confirmation. on a new line.
Add Planned target: Raise simulated completion to 70 out of 100 within 30 days after release. on a new line.
Add My role: Simulated Project Manager responsible for plan integration, risk visibility, status communication, and change control. on a new line.

Why Label the Numbers?

Northstar Market and its checkout figures are learning assumptions created for this capstone. Clear labels keep the case study honest.

The baseline describes the simulated starting point. The target describes the result your plan aims to reach after release.

Strong start. Your brief now shows a fictional company, a measurable problem, a planned target, and your simulated responsibility.

Define scope and stakeholders

Scope establishes the boundaries of the launch. The stakeholder list shows who contributes to the work or makes decisions about it.

Click the empty block below the role line.
Create a heading block by typing /h2.
Enter In Scope as the heading text.
Add Mobile checkout form simplification, address validation, payment-service integration, QA, and launch monitoring. beneath the heading.

The case study now names the work required to improve the existing checkout journey. This gives the launch a clear delivery boundary.

Create another heading block by typing /h2.
Enter Out of Scope as the heading text.
Add Guest checkout, loyalty rewards, new payment methods, and a storefront redesign. beneath the heading.
Create another heading block by typing /h2.
Enter Stakeholders as the heading text.
Add E-commerce Director as sponsor, Product Manager, Engineering Lead, UX Designer, QA Lead, Marketing Lead, and Customer Support Lead. beneath the heading.

What Do These Boundaries Prove?

The in-scope section shows where the team plans to spend time. The out-of-scope section protects the four-week plan from unrelated additions.

The stakeholder list makes decision authority visible. A viewer can identify the sponsor without guessing who approves major changes.

That boundary is doing real work. Your case study now shows what the launch includes and who has a stake in its delivery.

Add the milestone baseline

A milestone table turns the scope into a delivery sequence. Each row connects an outcome to its timing, owner, dependency, and current status.

Simple tables can feel fiddly at first. Build the structure one row at a time so every dependency stays aligned with the correct milestone.

Click the empty block below the stakeholder section.
Add a simple table by typing /table.
Select the first option.
Expand the table to five columns.
Expand the table to five rows.
Populate the top row with Milestone | Timing | Owner | Dependency | Status.

The top row now defines the five questions each milestone must answer. The four rows below provide the delivery baseline.

Populate the first data row with Requirements and design | Week 1 | Product Manager and UX Designer | sponsor approval | Complete.
Populate the second data row with Checkout build | Week 2 | Engineering Lead | approved design | In Progress.
Populate the third data row with Integration and QA | Week 3 | Engineering Lead and QA Lead | payment service available | Not Started.
Populate the fourth data row with Launch and monitoring | Week 4 | Project Manager | QA approval | Not Started.

Before you review the whole page, predict whether a recruiter could identify the problem, target, scope, stakeholders, and delivery sequence without opening another tool.

Scroll from the page title to the milestone table.
Confirm that Simulated Capstone Project remains prominent near the introduction.
Confirm that the table contains five columns.
Confirm that the table contains all four delivery milestones.

You should see the simulation label, problem assumption, planned target, scope boundaries, stakeholder group, and four milestone rows on one page. A viewer can now understand the launch plan without opening another tool.

Table Missing a Column or Row?

Count the table headings to confirm that the top row contains five cells.
Add the missing column or row from the edge of the table.
Compare each row against the milestone values above.

If the values still appear under the wrong headings, help me align my Notion milestone table.

Your case study now has a complete planning baseline that a recruiter can scan. Next, you will stress-test this smooth plan with delivery pressure.

Stress-Test the Checkout Launch

Your Notion case study now gives fictional Northstar Market a clear project baseline. A sponsor can trace the delivery target through its milestones.

A scenario stress test now challenges that smooth plan. You will introduce a delayed payment dependency plus a late guest-checkout request to reveal where the current plan stops short.

In this step, get ready to:

Document two simulated launch disruptions.
Show the impact on milestone health.
Create an unresolved stakeholder update.

Introduce the simulated disruption

Project plans become useful when they show what changed against the baseline. The Launch Update section keeps the new events separate from the original plan.

Create a heading below the milestone table by typing /h2.
Type Launch Update as the heading text.

You should see a new Launch Update heading directly below your milestone baseline.

Add These events are simulated inputs created for this capstone. below the heading.

The simulation label now makes the source of the scenario data clear to every reader.

Add today's date before the first scenario input: The external payment-service integration will be available five business days later than planned.
Add today's date before the second scenario input: Marketing requested guest checkout three days before the checkout build is due to finish.

You have the disruption in place. The original baseline now faces a believable test.

Why label the inputs as simulated?

The dependency delay is an authored learning input. The guest-checkout request is also fictional.

A clear simulation label protects the honesty of your portfolio story.

Show the baseline impact

Milestone health converts new information into a visible schedule signal. It also makes the scope pressure visible before anyone approves new work.

Change the Status value for Integration and QA from Not Started to At Risk.

You should now see At Risk beside the milestone that depends on payment-service availability.

Change the Status value for Launch and monitoring from Not Started to At Risk.

You should now see two downstream milestones marked At Risk.

Add this note below the milestone table: Impact: The payment-service integration delay compresses QA. Accepting guest checkout expands scope during the constrained schedule.

The pressure is visible now. A sponsor can trace both affected milestones back to the delayed dependency.

What Does At Risk Mean Here?

The At Risk label signals that the current schedule needs attention because the dependency delay compresses QA.

The label keeps the status grounded in a specific threat to delivery.

Write the unresolved status update

A status report gives stakeholders a concise view of project health. This update brings the blocker plus the scope pressure into one decision point.

Create a heading below the impact note by typing /h2.
Type Stakeholder Update as the heading text.

You should see a dedicated Stakeholder Update section below the impact note.

Add Overall health: At Risk.
Add Completed: Requirements and design.

The update now opens with the project's current health plus the work already completed.

Add Current blocker: payment-service integration delay.
Add Scope pressure: guest checkout request.

The sponsor can now see the schedule blocker plus the request putting pressure on the baseline.

Add Decision needed: protect the launch date, change scope, or move the release.

The update now ends with a decision request containing three possible paths.

Before you read this as the sponsor, do you think the update tells you which response to approve?

Read from Launch Update through Decision needed as if you are the sponsor.

You'll see At Risk plus the five-business-day dependency delay. You'll also see a decision request with three paths.

The update has no recommended response, assigned owner, mitigation, or checkpoint. That shortfall is intentional because this version demonstrates the limit of status reporting alone.

You've reached the intended turning point. The visible launch problem still lacks an executable response.

Your stress test now shows where the baseline breaks under pressure. Next, you'll turn the unresolved decision into a controlled response.

Control the Risk and Scope Change

Your Notion case study now shows an honest At Risk moment. The launch pressure is visible to the sponsor.

The unresolved update still has no owner or executable response. This leaves bad news without a decision path.

In this step, you will use a risk register to assign ownership. You will use change control to make a defensible scope recommendation.

A recovery plan will convert that recommendation into timed action.

In this step, get ready to:

Build a risk register with owners, mitigations, triggers, and statuses.
Compare three scope options in a Decision Log.
Add a recovery plan and update the stakeholder message.

Build the risk register

A risk register turns each uncertainty into a tracked item. Likelihood and impact show which risks need the most attention.

Switch back to the E-commerce Checkout Launch Case Study page from earlier.
Place your cursor below the unresolved stakeholder update.
Add Risk Register as a heading.
Create a simple table by typing /table on a blank line.
Select the first option.
Use the control on the table's right edge to expand it to seven columns.
Set the header row to Risk | Likelihood | Impact | Owner | Mitigation | Trigger | Status.
Populate the first data row with Payment integration delay | High | High | Engineering Lead | escalate with the service provider and test non-payment paths in parallel | integration unavailable at the 48-hour checkpoint | Open.

The payment delay now has a named owner. Its trigger creates a clear point for escalation.

Populate the second data row with Guest checkout scope creep | Medium | High | Project Manager | require sponsor approval and defer the request unless schedule or budget changes | approval requested after baseline | Controlled.
Populate the third data row with Mobile checkout defects | Medium | Medium | QA Lead | prioritize critical-device tests and define release-blocking defects | critical defect remains open at go/no-go review | Open.
Scan each row from left to right.

You should see an owner beside every risk. Each row should also include a mitigation, trigger, and status.

How Does a Risk Register Help?

Likelihood and impact make priority visible. An owner makes accountability explicit.

Mitigation defines the planned response. A trigger tells the team when that response needs escalation.

Record the scope decision

The risk register organizes exposure. The Decision Log captures the tradeoff behind your recommendation.

Comparing realistic options shows that you considered schedule, scope, and value before choosing a response.

Place your cursor below the risk register.
Add Decision Log as a heading.
Add Option 1: Add guest checkout now and move the release date. as the first option.
Add Option 2: Protect the current launch scope and defer guest checkout to a follow-on release. as the second option.
Add Option 3: Remove mobile form simplification to make room for guest checkout. as the third option.
Add Recommendation: Protect the current launch scope and defer guest checkout to a follow-on release. below the options.
Add this rationale beneath the recommendation: This preserves the validated checkout objective. This avoids adding work during compressed QA. This keeps the guest checkout request visible for later prioritization.

Read the three options in order. You should see a distinct tradeoff between schedule movement, scope protection, and removing validated work.

Why Protect the Current Scope?

The current scope directly supports the planned checkout-completion target. Adding guest checkout introduces more work while QA time is already compressed.

Deferral keeps the request visible for later prioritization. Sponsor approval preserves accountability for the baseline change.

Add the recovery plan

A recovery plan turns the selected option into timed work. The stakeholder message then names who owns the next move.

Place your cursor below the Decision Log.
Add Recovery Plan as a heading.
Add Test non-payment checkout paths while the integration is delayed. as the first action.
Add Hold a 48-hour integration checkpoint with the Engineering Lead and sponsor. as the second action.
Add Keep overall health At Risk until integration and release-blocking tests pass. as the third action.

The recovery plan now protects useful testing time during the delay. It also prevents the health label from changing before the evidence supports it.

Return to the compact stakeholder update from earlier.
Keep the existing health, completed, blocker, and scope pressure lines.
Find the line that starts with Decision needed:.
Replace that line with Recommendation: Protect the current launch scope and defer guest checkout..
Add Owner: Project Manager with Engineering Lead and sponsor involvement. below the recommendation.
Add Checkpoint: 48-hour integration checkpoint. below the owner.
Add Approval needed: Sponsor approval of scope protection and deferral. below the checkpoint.

Before you check the page, do you expect both disruptions to connect to a named owner, response, and checkpoint?

Trace the payment integration delay from the Launch Update through the risk register, recovery plan, and stakeholder update.
Trace the guest checkout request from the Launch Update through the risk register, Decision Log, and stakeholder update.

You should see the payment delay assigned to the Engineering Lead. Its mitigation tests non-payment paths in parallel.

The 48-hour checkpoint provides the escalation point. Overall health remains At Risk until integration and release-blocking tests pass.

You should see the guest checkout request assigned to the Project Manager. The Decision Log defers it to protect the current scope.

The stakeholder update asks the sponsor to approve that recommendation. You've closed the gap between reporting a problem and controlling it.

Your case study now shows structured judgment under pressure. Next, you will frame these controls as an honest portfolio story and publish one shareable link.

Publish the Case Study

Your case study now shows a credible response to a delayed dependency. It also documents how you handled late scope pressure.

A recruiter still needs to understand your contribution without translating internal project artifacts. This step frames your judgment as a simulated case study before you publish it as a public Notion Site.

In this step, get ready to:

Add a concise narrative that explains your role and decisions.
Remove private content from the case study.
Publish the case study as a public site.

Add the case-study narrative

Project artifacts show what happened inside the scenario. A case-study narrative explains what you owned and why your decisions mattered.

Use an honest case-study voice

My role: As the simulated Project Manager, I owned plan integration. I also owned risk visibility. I handled status communication. I controlled scope changes.
Constraints: The simulated baseline covers four weeks. The plan depends on an external payment service. QA time remains fixed.
Key decision: I recommended deferring guest checkout. This protects the validated checkout-improvement scope.
Planned success measures: I would track checkout completion. I would track release-blocking defects. I would track schedule variance. I would track post-launch support issues.
Reflection: This exercise reinforced the value of raising risks early. It also showed why stakeholder requests must stay separate from approved scope.

Add five heading blocks beneath the recovery plan using the labels in the callout.
Place each matching narrative beneath its heading.
Read the sequence from My role through Reflection to confirm that each section is concise.

You should see five compact sections beneath the project-control artifacts. They show the judgment behind your simulated work.

Run the recruiter and privacy review

A public portfolio earns trust when its claims are easy to scan. Every fictional figure also needs clear simulation language.

Review the opening summary to determine whether a recruiter can read it before reaching the first table.
Shorten the summary if it extends into the first table.
Confirm that Simulated Capstone Project remains prominent near the top of the page.
Review every fictional metric for simulation language.
Rewrite any current figure as an assumption or simulated baseline.
Rewrite any future figure as a planned target.

The current checkout figure should read as a simulated baseline of 60 confirmations per 100 starts. The future figure should read as a planned target of 70 per 100 within 30 days after release.

Check What Becomes Public

Anyone on the web can view a published Notion Site.

Subpages are published by default with the site. Their permissions can be restricted.

Published metadata can include contributor names. It can also include profile photos or email addresses associated with contributors.

Publishing changes who can see the page. This review gives you control before that happens.

Search the case-study page for personal email addresses.
Delete every personal email address that appears.
Search the case-study page for private notes.
Delete every private note that appears.
Review the page tree in the left sidebar to identify any unrelated subpages beneath the case study.
Move every unrelated subpage outside the case-study page.
Reread the case study to confirm that every remaining section supports the checkout launch story.

Your page should now contain only the simulated case study and its supporting project controls. Every metric should be framed as an assumption or planned target.

Publish and inspect the public site

Publishing turns the workspace page into a link that anyone can open. Changes you make to the published page update the site automatically.

Select Share at the top of the case-study page.
Open the Publish tab.
Select Publish to make the case study public.

Before you open the published page, which parts of the case study do you expect a recruiter to notice first?

Select View site to inspect the public version.

You should see the public case study in a new browser view. The title and simulated-capstone label should be visible near the top.

Review the top of the public page to confirm that your name and target role are readable.
Scroll through the public page to confirm that the project brief and milestone table are visible.
Continue to the At Risk update to confirm that the launch disruption is clear.
Continue to the risk register to confirm that the owners and mitigations are readable.
Continue to the Decision Log to confirm that the scope recommendation is visible.
Continue to the reflection to confirm that the case study ends with your learning.
Copy the public link. Record it here: your public notion.site URL.

The published view should show the simulated-capstone label and every project-control artifact. Its layout should remain readable from the opening summary through the reflection.

Can't See the Published Case Study?

Return to the case-study page from earlier. Confirm that you selected Publish inside the Publish tab.

If a recent edit is missing from the public view, refresh the site after confirming that the edit appears in your workspace page.

Help me troubleshoot my Notion Site publication

Your simulated checkout launch is now a public portfolio case study. Recruiters can see how you plan work, surface risk, control scope, and communicate a recovery decision.

Secret mission

Add a One-Minute Executive Dashboard

Your full case study proves depth. This mission adds a compact dashboard for a one-minute executive scan of the project goal, health, top risk, owner, and decision.

Clean Up Your Resources

The Free plan leaves this portfolio with no ongoing cost. Choose whether to keep the Site public, pause public access, or delete the portfolio page.

Resources you used:

The public Notion Site for E-commerce Checkout Launch Case Study at its notion.site address.
The private E-commerce Checkout Launch Case Study page in your personal workspace.

Keep everything running

No action is required. Choose this option if you want recruiters or interviewers to keep accessing your case study.

Keep the Notion Site published.
Use the public link in your resume or applications.

Pause - I'll come back to this later

Pause public access while keeping the private case study ready for future edits.

Switch back to the E-commerce Checkout Launch Case Study page in your personal workspace.
Select Share at the top of the page.
Open the Publish tab.
Select Unpublish.

Your case study remains private in your workspace. You can edit it or publish it again later.

Delete - I don't want to use this again

This option removes the public Site and portfolio page. Notion moves the deleted page to Trash for 30 days by default.

Switch back to the E-commerce Checkout Launch Case Study page in your personal workspace.
Select Share at the top of the page.
Open the Publish tab.
Select Unpublish.
Select ••• at the top right of the page.
Select Delete.

You will see the portfolio page in Trash. Your personal workspace remains available for future projects.

Nice Work!

You did it! You've turned the simulated Northstar Market launch into a public Notion case study.

You've learned how to:

Created an honest portfolio story that labels Northstar Market as fictional. Presented every metric as an assumption or planned target.
Built a project baseline around business value. Defined scope boundaries. Named stakeholder roles. Set planned success measures. Mapped four delivery milestones.
Turned an At Risk disruption into a defensible recommendation. Assigned owners. Documented mitigations. Set escalation triggers. Established a 48-hour integration checkpoint.
Secret Mission: Added a one-minute executive dashboard that surfaces project health at a glance. Identified the top risk. Named the responsible owner. Put the sponsor decision first.

Ready to quiz yourself?