Prioritization Roadmap

This page decides the order of the work. A redesign this size cannot be built all at once, especially by a team of 8 engineers with limited resources. So we must be strict about what comes first.

We order the work by two measures.

• Impact means how much a change moves the main business result, which is the number of applications an employer receives per open job. The CTO-confirmed target is 20–40 applicants per promoted post. A change has high impact when it moves one of the two levers behind that target: conversion (more visitors apply) or distribution (more visitors see the post).
• Effort means how much engineering work the change needs. A change has low effort when the frontend can do it alone, and higher effort when it needs new backend work such as database changes or new filters.

The best work to do first is high impact and low effort. The work to do last is low impact and high effort.

The IA concepts behind this page

• The order of work uses an impact-versus-effort ranking, also called an Action Priority Matrix, and related value-versus-effort methods such as RICE. Do the high-impact, low-effort work first.
• The decision to sell distribution together with the conversion fixes is a business argument about traffic and funnel economics, not an information-architecture concept. We state it plainly for that reason.

For the full list of concepts and sources, see Theory & Method Foundations.

The guiding sequence

Before the detailed list, here is the most important rule for the order of work — and an honest correction, because the earlier version of this page had the order wrong.

The old order was: 1) fix the funnel, 2) grow the number of applicants, 3) only then sell visibility. The logic sounded careful: do not charge employers for visibility inside a funnel that loses everyone. But the per-post arithmetic breaks that logic. Walk through it:

1. The median careers post gets about 19 unique visitors in 90 days (see the Overview, Finding 2).
2. Imagine the funnel becomes perfect and 100% of visitors apply. The median post still gets only about 19 applications. Conversion work alone can never reach the target of 20–40 applicants per promoted post, because it cannot push past the traffic ceiling — and real funnels convert a few percent, not 100%.
3. Growing total traffic is slow: organic search brings about 960 clicks per month and has been flat for 3 months. Waiting for traffic growth before selling means waiting a long time with an unsellable product.
4. Meanwhile, a client who pays $400 for a post is buying applicants, not a listing row. Today the post is a listing row that a median of 19 people ever see.

So the mistake in the old order was not "selling too early". The mistake was selling posts with no distribution attached. The fix is to build the distribution bundle — featured pinning on the /jobs list, a home featured rail, cross-links, job-alert emails — and sell that. The bundle routes the traffic the site already has (the /jobs list gets 35,914 views per quarter) onto the posts that pay. It also reuses the paid-placement infrastructure that already exists in the ads work.

The new order:

1. Measure and unblock (days). Add the native apply event and remove the cheap blocks, so every later change can be proved.
2. Fix the careers apply flow and build the distribution bundle — together. Conversion and distribution are the two levers of the same target. Neither is enough alone: a perfect funnel on 19 visitors gives 19 applicants, and heavy traffic into a 0.68% funnel gives almost none.
3. Then improve the list, the card, and the taxonomy. These raise the quality of every visit to the most-used page.
4. Then acquisition and the home page. Grow total traffic once the site can convert it and distribute it.

Impact and effort of each change

This table lists the main changes, what each one fixes or serves, and its impact and effort. It is sorted roughly from the best first-choices at the top. "Friction" numbers refer to the Friction Points page.

Change	Fixes / serves	Impact	Effort	Needs backend?
Add a jodapp.com-native apply event	Friction 3 (measurement)	High	Low	Small
Fix the sign-up → login bounce (log the user in when the OTP is confirmed)	Friction 3	High	Low	Small
Add a sticky Apply button on the careers job page	Friction 2	High	Low	No
Add keyword chips on the home page and job list	Friction 1	Medium–High	Low	No — the words already render as static text next to a working search handler
Expose a "Best match" sort label, and add a "Highest pay" sort	Friction 4	Medium	Low	Small — "Best match" needs none; "Highest pay" is one more allowed order value
Resolve the ad slots with billing: remove the AdSense fallback, keep the paid placements	Frictions 1 and 2	Medium–High	Low	No — but it needs a billing decision first, not a code change alone
Redesign the apply flow: record the application first, lightest identity step (Principle D)	Friction 3	Very High	Medium–High	Yes
Add 1–3 screening questions after the application is recorded	Applicant quality	High	Medium	Yes
Align the login UI with the Fluid Identity model (one login, Principle D)	Friction 3	Medium	Medium	Small
Featured pinning of paid posts on the /jobs list	Distribution (the sellable product)	High	Medium	Yes — reuses the existing ads-placement infrastructure
Home-page featured rail	Distribution	Medium–High	Medium	Yes — same infrastructure
Add "similar jobs" and "more from this employer" to the job detail page	Friction 2 + distribution	Medium–High	Medium	Small
Job-alert emails to registered talent	Distribution	High	Medium–High	Yes
Redesign the job card (pay prominence, outlet name, honest badges)	Friction 1	High	Medium	Small
Add a daily-pay badge and filter	Friction 1	High	Low or Medium	Depends on one business rule — see below
Add a category filter	Friction 1	High	Medium	Yes — a btree index, CATEGORY_MAP reconciliation, and a backfill
Make employer and outlet the main location filter	Friction 1	Medium	Low–Medium	Mostly exists — meaningful for gig only, until careers outlets are real
Build the Companies hiring list and a featured-employers row	Discovery	Medium	Medium	Small — but the featured-employer flag has no spec; write the spec first
Build category landing pages for Google	Acquisition	Medium	Medium	Small
Redesign the home page	First impression	Medium	Medium–High	No
Add the featured-employer flag set by sales	Monetization	Medium	Medium	Yes — no spec exists anywhere; write the spec first
Build the job boost product	Monetization	Medium	High	Yes — needs the billing entitlement engine, Phase 3 of the ads billing work (38-ads, billing-integration-phase-2)

Evidence: Assumption

The impact and effort ratings above are our estimates, based on the friction data and the backend audit — they are not measured outcomes. Confirm them as you scope each change, and re-rank if the effort or impact turns out different.

Two rows from the earlier version of this table are gone, and the reasons matter:

• "Fix search ordering so relevance is used first" is removed, because the bug does not exist. The code review showed that relevance already ranks first whenever a search term is present. The real gap is that the interface hides this and offers no sort choices. The row is replaced by the "Best match" + "Highest pay" sort row. The full correction is in Friction Points, Friction 4.
• "Remove the ads" is replaced by a billing decision. The three ad slots are our own paid campaign placements with an AdSense fallback, not plain AdSense. Deleting them would delete sellable inventory — the same inventory the featured-distribution product will use. The action is: confirm sold campaigns with billing, remove only the AdSense fallback from the list and detail slots, keep the placement capability. Owner: billing/product.

The daily-pay badge depends on one business rule. No payment-timing field exists anywhere — not in jodapp-api, not in the JodGig sync, and not in the target gig schema. There are two paths:

• If the business commits to the rule "every gig job pays the next day", the badge and the filter are only a frontend rendering of employment_type = gig. Zero backend work.
• Without that rule, the true cost is a new column on listings_jobs, changes to both projection builders (the careers sync and the gig sync), and a one-off backfill.

We recommend adopting the rule. Until then, treat this as an open business decision. Owner: product/ops.

The phased plan

The changes above are grouped into phases. Each phase has a clear goal, and each phase states the result metric and its current baseline, so we can see whether the phase worked.

Phase 0 — Measure and unblock (days)

The goal is to make every later change provable, and to remove the blocks that are cheap to remove. Everything here is days of work, not weeks.

• Add the jodapp.com-native apply event. Today the site's only completion signal is 18 generate_lead users in 90 days (careers only), the "apply start" number is a form_start proxy that never fires on a job page, and gig completions can only be traced across hosts (about 60–65% of them). One event, fired when the user taps Apply, for both job types.
• Fix the sign-up → login bounce: a new user who confirms the email OTP must be logged in, not returned to the login form.
• Add the sticky Apply button on the careers job page. The button already exists mid-page, and the sticky pattern already exists on the home page bottom navigation.
• Add the keyword chips on the home page and the job list. The words already render as static text next to a working search handler, so this is genuinely low effort.
• Resolve the ad slots with billing: confirm which placement keys have sold campaigns, remove the AdSense fallback from the job-list and job-detail slots, keep the paid-placement capability. Owner: billing/product.
• Expose the "Best match" sort label (shown as active whenever a search term is present) and add the "Highest pay" sort.

Result to measure: completed applications become measurable natively on jodapp.com, for both job types. Baselines to beat once measured: careers conversion 0.68% (18 of 2,646 careers detail users in 90 days), list-to-detail 47% (53% of list users open no job).

Phase 1 — Fix the careers apply flow (the conversion lever)

The goal is to stop losing users who already decided to apply. Today the careers path demands: login, sign-up with OTP, a second login caused by the bounce, and a 6-step wizard with 3 hard gates — all before the application is recorded.

• Record the application first, with the lightest possible identity step. This aligns with Principle D, Fluid Identity: one Identities::User with gig and careers personas is already the documented model, so the flow change follows doctrine, it does not invent it.
• Move profile completion after the application, in small steps.
• Add 1–3 employer-defined screening questions, asked after the application is recorded and shown to the employer with the application. This restores applicant quality: the client complaint was not only "2 applicants" but "none qualified". Volume fixes reduce the information each application carries; the screening questions put it back without blocking the apply.

Result to measure: careers detail visitor → recorded application. Baseline today: 0.68%. Direction: toward the gig benchmark of about 4.4% — the rate users complete on gig-partners, a worse experience than the one we are building, so it is a floor, not a ceiling.

Phase 2 — Build the distribution bundle (the sellable product)

The goal is to make a promoted post reach hundreds of the visitors the site already has, instead of the median 19. This is what a paying employer is actually buying, so this phase runs next to Phase 1, not at the end of the roadmap.

• Featured pinning of paid posts on the /jobs list — the site's biggest surface, 35,914 views per quarter.
• A home-page featured rail.
• "Similar jobs" and "more from this employer" on the job detail page, so paid posts also catch the 25.2% of sessions that land directly on some other job page.
• Job-alert emails to registered talent.
• The featured-employer flag for sales. No spec exists anywhere for this flag, so the spec must be written first.

The job boost product (a paid ranking boost bought per job) follows the bundle later. It needs the billing entitlement engine, which is Phase 3 of the ads billing work (38-ads, billing-integration-phase-2).

Result to measure: unique visitors per promoted post (baseline: median 19 in 90 days → target hundreds), and applications per promoted post (baseline: the reported 2 → target 20–40, CTO-confirmed).

Phase 3 — List, card, and taxonomy

The goal is to raise the quality of every visit to the list, which is the most-used page and the largest drop-off.

• Redesign the job card: make pay prominent (careers pay is hidden unless the employer opts in), show the outlet name (today the card shows only a coarse area such as "Tampines"), and add the honest daily-pay badge — pending the business rule above.
• Add the category filter, with the CATEGORY_MAP reconciliation, the btree index, and the backfill. The reconciliation is not optional: gig listings can only emit 7 category values, and the careers seed has 89 names that do not include "Logistics" or "Others". Shipping without reconciling shows the user two mismatched vocabularies in one filter.
• Add the employer/outlet location filter. The backend filters mostly exist already; the filter is meaningful for gig jobs only, until careers outlets are real — every careers job today carries the placeholder outlet hq.

Result to measure: list-to-detail rate. Baseline today: 47% (53% of list users open no job; 67% on desktop).

Phase 4 — Acquisition and the home page

The goal is to grow total traffic, now that the site can convert it (Phase 1) and distribute it (Phase 2). Acquisition is a first-class workstream here, not a side effect.

• Build the category landing pages, which give Google more indexed pages that can rank.
• Run the SEO workstream as planned, ongoing work. Organic search brings about 960 clicks per month and has been flat for 3 months. The ceiling is impressions: we can only get more clicks by ranking more pages for more queries. The tactics live in the marketing docs (74-marketing).
• Redesign the home page to show categories, featured employers, and the keyword chips.

Result to measure: organic clicks per month (baseline: about 960, flat), and total users entering the job list and the job detail pages.

What to design first

Because this is an architecture document that comes before screen design, here is the order in which to design the actual screens once this IA is agreed.

1. The apply flow and its confirmation screen. The apply flow targets the deepest loss (0.68%), and the confirmation screen is where the account completion and the screening questions are invited — after the application is captured, never before.
2. The job detail apply area. The sticky Apply button and the "similar jobs" module. This is the second-largest drop-off, and the entry point for the 25.2% of sessions that land directly on a job page.
3. The featured placement and the job card. The featured pinning is the sellable product, and the card is the smallest repeated unit — the home page, the job list, the company page, and the saved-jobs list all use it.
4. The job list and its filters. The chips, the category filter, the sorts, and the location filter.
5. The home page. After the core loop and the distribution surfaces, not before.

One sentence to remember

Fix the careers apply flow and build distribution at the same time: conversion alone cannot beat the traffic ceiling (a median post gets about 19 visitors), and traffic alone cannot help a funnel where only 0.68% complete.