How software works · Guide for product managers

Frontend for product managers

The frontend is the part of your product users actually see and touch. Knowing how it is built explains why "just move this button" takes five minutes while "show this number here" can take a sprint — and helps you make better calls on performance, SEO and accessibility.

Guide 2 of 13 in the technical PM path

10 min read · Updated 25 September 2026 · By the TechPMer team

Why a PM should care

• Estimates make sense. A layout change touches the frontend only; new data on a screen usually needs the backend and API too.
• Speed is a product feature. Slow pages lose users and sign-ups, and much of that speed is decided in the frontend.
• SEO and sharing depend on how pages are rendered — a decision made early and expensive to reverse.
• Accessibility is mostly frontend work, and in many markets it is a legal requirement.

The three layers of every web page

Everything a browser shows ends up as these three, no matter which framework produced them.

Frameworks and components

Writing large apps in plain JavaScript gets messy, so most teams use a framework — React is the most common, alongside Vue, Angular and Svelte.

Their key idea is the component: a reusable piece of UI with its own structure, style and behaviour — a Button, a PricingCard, a TaskList. Screens are built by combining components, which is why a design system (a shared set of components) makes teams faster and the product more consistent.

<TaskCard title="Write release notes" dueDate="2026-10-01" status="open" />

Here title, dueDate and status are props — the data passed into the component. If the API does not provide a field, the component cannot show it.

State: what the screen remembers

State is the data the UI currently holds: the text in a search box, whether a menu is open, the list of tasks loaded from the server, who is signed in.

Many frontend bugs are state bugs:

• the list does not update after you create an item (the local state was not refreshed);
• two parts of the page show different numbers (the same data is stored in two places);
• a form loses what you typed when you switch tabs (state was not kept).

When engineers talk about "state management", they mean deciding where each piece of data lives and how changes flow through the screens. Specific libraries come and go; the underlying question stays the same.

SPA vs server rendering (and why it matters for SEO)

Many products mix them: static or server-rendered marketing and content pages, and an SPA behind login. That is a product decision as much as a technical one.

Performance basics

Google's Core Web Vitals summarise what users feel:

• LCP (Largest Contentful Paint) — how quickly the main content appears.
• INP (Interaction to Next Paint) — how quickly the page responds to clicks and taps.
• CLS (Cumulative Layout Shift) — whether things jump around while loading.

Common causes of slowness: huge images, too much JavaScript, many sequential API calls, and fonts or scripts from third parties (chat widgets, trackers). Every "just add this script" request has a performance cost.

Accessibility

Accessible frontends work for people using keyboards, screen readers, zoom or high-contrast settings. The basics are simple and cheap when built in from the start: real buttons and links (not clickable divs), labels on form fields, enough colour contrast, visible focus, and alt text on meaningful images. Retrofitting later is much more expensive.

What engineers may tell you

• "That's a backend change, not just UI." The data you want to show is not available to the frontend yet.
• "It's a hydration issue." The server-rendered HTML and the JavaScript disagree, causing flicker or errors.
• "The bundle is too big." Too much JavaScript is downloaded before the page works.
• "We need a loading and empty state for this." Every screen that fetches data has at least three states: loading, empty and error — plus success.
• "Let's add it to the design system first." Build the component once, reuse it everywhere.

Questions a good technical PM asks

1. Which states does this screen have — loading, empty, error, success, no permission?
2. Does this change need new data from the API, or only a UI change?
3. Does this page need to be indexed by search engines or shared on social media?
4. How will this behave on a slow phone and a small screen?
5. Can it be used with a keyboard and a screen reader?

Red flags

• Designs that only show the "happy" state with perfect data.
• Secret API keys in frontend code — anything in the browser is public.
• Public marketing pages built as a client-only SPA with no plan for SEO.
• Adding third-party scripts without checking their impact on speed and privacy.

Using an AI coding agent for frontend work

Agents are very good at building components quickly. Give them the design (a screenshot helps), the states you expect, and constraints: "use our existing Button and Card components", "mobile first", "keyboard accessible", "no new dependencies". Then check the result on a real phone and with the keyboard only (Tab, Enter, Esc).

Try it yourself

Open your product in the browser, press F12 and use the element picker to click any button. You will see its HTML and CSS. Then open the Lighthouse tab and run a report — it scores performance, accessibility and SEO and lists concrete improvements you can bring to your team.

In the TechPMer course, week 4 (“Choosing the Stack”) covers SPA vs SSR decisions and week 5 (“Scaffold the App & Build the Frontend”) builds the frontend of your own project with an AI agent.