“Tell us about a feature you owned”: a structure that works

It comes up in product, engineering and design interviews in one form or another: tell us about something you owned. Most answers are either a tour of the whole project or a list of tasks. Neither tells the interviewer what they asked.

The question sounds open, which is why it's hard. There's no right feature to pick, and the pressure to say everything is real. A simple structure takes that pressure off: four beats, in a fixed order, that fit in about ninety seconds out loud.

What the question is really asking

"Owned" is the word to listen for. The interviewer wants to know what happens when something is yours: how you decide what to build, how you work with the people around you, and whether you follow through after it ships. The feature is just the setting.

So choose a story where you made calls. A small feature you shaped from the first sketch to the release says more than a large one where you took tickets. If you're early in your career, a piece of a feature counts, as long as the decisions in that piece were yours.

Four beats in ninety seconds

1. 01
   The scale, in two sentences

   What it was, who used it and why it mattered. "A booking flow for a clinic app, used by patients to book their own appointments. Most bookings still came in by phone."

2. 02
   Your part, for most of the time

   What you decided and did, in the first person. "I proposed splitting it into three steps, tested two versions with five patients, and built the one that fewer of them got stuck in." Say "we" only for what the team did together.

3. 03
   The result

   What changed, with a number if you measured one, and how you knew. If you didn’t measure it, say what you saw instead: fewer support calls, a process that stopped needing a workaround.

4. 04
   What you’d change

   One honest sentence about what you’d do differently. It shows you kept thinking about the work after it shipped, and it invites the next question on your terms.

The same story told twice

Here's how the same feature can come out, first as a tour and then in four beats.

As a tour: "So I worked on the booking project at a clinic app. It was a big project with a lot of moving parts, we had design, backend, mobile. We had a lot of meetings about scope. I did a lot of the frontend and some of the testing. It went live in the spring and people liked it."

In four beats: "Patients at our clinic app could only book by phone, and the front desk was spending hours a day on it. I owned the web booking flow. I proposed three short steps instead of one long form, tested both with five patients, and built the one where nobody got stuck. After launch, online bookings overtook phone bookings within a few months. I'd run the test earlier next time: we almost built the long form."

The second answer is shorter and says more. Every sentence either sets the scene, shows a decision or proves an outcome.

The feature is the setting. Your decisions are the story.

Questions to expect next

A good answer invites follow-ups. Have a sentence ready for each of these:

Practise it out loud

Structure only helps if you can say it without reading. Write the four beats as a few words each, then say the answer out loud and time it. Most first attempts run long in the first beat. Cut there, not in your part.