Last year, my husband and I inadvertently fell in love with a house in the Hudson Valley. Buying a property in New York City is pretty unattainable for most mere mortals, so we found ourselves stalking through Instagram like the millennials we are, and suddenly, there it was. The house needed work, and we were foolhardy enough to think we could fix it up ourselves.
Renovating a house has taught me excellent skills like how to tile a bathroom, how to renovate a kitchen for $500, and how to solve any color dilemma (hint: Shoji White or Tricorn Black). What I couldn’t have known when we embarked on this journey, though, was that renovating a house would teach me more about product management than any book or conference ever could.
The most significant learning curve has been how to manage scope creep: the tendency for every single software product to bloat with all the “shoulds,” “coulds,” and “woulds” imaginable. Designers tend to introduce scope creep by frankly being too good at their jobs. A designer may suggest that a feature set would be so much more powerful if it did x, y, and z — instead of just doing z. They’re not wrong, but it might not be the right time for the client, or we don’t have user data to validate that route, or it could be a considerable engineering lift. We have to frame the right moment to add x and y into the product. Sometimes the time is now, and other times it would be better to tackle further down the line.
Engineers can add to scope creep when things are poorly defined. It’s important to be specific with what is in and what is out of each piece of work in the roadmap. Otherwise, you could end up with two people building the same thing from two approaches, or erroneously focus on scalability for an app with a small, specialized user base.
Saying No to Quick Wins
Handling scope creep on something physical — like a home renovation — is a real test, because it’s so hard to keep the big picture in mind consistently.
Why is this hard? With software, I’m continually writing requirements, reviewing designs, QAing, and thinking about where we are right now versus where we are going in two weeks, two months, and two years. Creating a product is thought driven, something the team holds collectively, but a house renovation is different.
So, like any truly organized person, when we bought the house I started a Gantt chart to track our progress. For the first four months, we followed this faithfully, jumping from one high priority to another. We took on problems like the water softener corroding the inside of our pipes (not fun) before painting the kitchen (fun). It seems obvious to start with basics, but sometimes it’s incredibly hard to say no to those quick wins.
Quick wins can stump a product, too. That’s why for product development, it’s so imperative to have regular video or IRL stand-ups where engineers can talk through their approaches rather than slide by with a one-line update. It’s essential to have a formalized process for tracking tasks — for example, in a tool like Jira — especially for a larger team. If there’s no ticket, you can’t make sure it’s correctly prioritized, and others in the same area of the codebase won’t be aware. AKA, a total nightmare.
Having a close relationship with clients is also crucial. Otherwise, they can become the biggest culprit for scope creep by introducing new wants constantly. Spending time working with clients to define the scope of the product for v1, v2, or even all the way through v7 is time well spent. Preparation upfront is essential to avoid problems down the line, which can rupture timelines and trust if the missed deadline or neglected feature is vital to the client.
Eye on the Prize of Product Vision
Managing scope creep introduced by other members of the team is a sea I’m used to navigating whilst always keeping my eyes on that North Star product vision. What I’m less used to, however, is saying no to myself — and that’s difficult to admit. As a product manager, I need to make decisions for the product’s direction based on the best information I have at the time, while also keeping a bird’s-eye view of the product as a whole.
It’s hard to keep the whole product in your mind when everything is behind walls. In renovation, these physical walls limit my imagination, and I get drawn towards the things which would be fun to do or look great with minimal effort. It’s hard to stand in a house and see all the areas that aren’t yet done. The trim, the dust, the floors. The terrible green that the previous owners painted every room, the extra cement bag we bought months ago and still need to return to Lowes, and the seventeen tubes of stretch caulk for all the paneling. It’s not restful. It’s not glamorous. It’s nothing like it looks on HGTV with homeowners and their perfect blowouts. Instead, I have flecks of paint in my hair that look like dandruff.
When you look at the wall you’ve finished skim coating — and know that really it would need two more coats before sanding, priming, painting, and finally applying the trim — you know that the process is long but ultimately rewarding. But you have to draw the line somewhere, or you’ll never stop. It’s rewarding to say no to yourself. To not be distracted by more manageable tasks and stay the course. It’s learning in a whole new capacity outside of your comfort zone, and when you finally scrub all the paint off your hands, you realize it’s transformational for the product manager inside you, too.