How to decide what to build: scope, context, and conversations
And why templates are only half of the story
Welcome to RemoteThatWorks, a weekly-ish newsletter hand-typed by the Valentina Thörner, the Empress of Remote herself. I talk about product leadership (and ops), process design, and people (and their relationships). Proudly non-AI, and proudly all-opinions-my-own. To work with me, find me on MentorCruise. Oh, and subscribe so you don’t miss out on the next post.
You want to build the right thing, fast. While the company is small, that is relatively easy. Everyone understands the market and the product, everyone gets exposed to customers. Both customer success and engineering understand what’s needed.
As you grow, people specialize. You start hiring outside of your own industry, for specific non-customer related skills. And suddenly your backend developer may not be aware of the realities of your customer.
And now is the moment where your product managers need to step up.
For your engineering team to be successful and fast, product managers need to 1) define the scope, 2) share context, and 3) makes sure the message gets across (communication).
You can solve #1 and #2 with templates. You have to follow up both with the human touch so you can empower your engineering team to add their own improvements.
Scope: To think outside the box - you need a box
“Scope” is the extent of the area or topic that something deals with or to which it is relevant.
Or, in other words, scope tells engineering teams what good enough looks like, so they can create a meaningful solution for customers in a reasonable amount of time. Scope adds constrains - and constrains allow for better decisions.
That doesn’t mean that scoping is easy. As a product manager you will get pushback as you define what good enough looks like. It’s tempting to add just one more tiny change so that [insert critic] leaves you alone. It’s also destructive.
This is where templates can be helpful. They allow you to clearly define scope, highlighting supporting data points, and defining what not to do and what to do later. A well defined scope is the best way to speed up development.
Context: Explaining the location of the box
Now that you are clear on your scope, ready to discuss your requirements with the engineering team - it’s time to call for a meeting. Yes! This is one of the times where a meeting can be helpful, especially if your company culture came late to remote work.1
Share your scope and your requirements before the meeting and have an open discussion about where the scope came from and what it means for real life situations. Your engineering team might not be an expert in your customers’ reality, so you need to give them the context they need to create the best solution.
Why is this problem worth solving? Why are customers frustrated with the current situation? How should the solution impact their behaviour? How do you plan to measure impact? Be ready to answer all the questions - and be wary if they don’t ask any questions! They may agree - or they may not agree and go the “whatever” route.
At the end of the meeting you should be confident that your scope is realistic and the engineering team should be confiendt they understand the problem that you are going to solve together.
It requires a template and some written documentation. And it also requires a conversation with everyone involved.
Some examples of scope and context
Here are some examples that seem obvious as you write them down. They are obvious to you who’ve been deep in research about this problem for several days already. So I’ll give you the questions that you should expect from your engineering counterpart.
Reliable [data]
“Customer expect reliable delivery information when ordering a product.”
What does reliable mean in this context? Should the information be based on information shared by the carrier? Should you include known performance by the carrier into the equation? What about frequency of updating that information? Is one email enough or do you require regular emails with updates? Which type of updates? Or do you need a delivery status page to avoid email overload?
If this is the first time you are looking nto “reliable delivery information” - what’s the smallest version of reliable you can come up with? Why do you think customers can life with that smallest version? Which are the moments where customer are most likely in need of the information.
API integrations
“We want to offer an API integration for those delivery partners who want to share live updates with our system.”
Which type if information is currently available in your partners’ feeds that might be useful for you? How does that information differ across partners? Is there a specific format that you need? Does “live updates” mean continous real-time updates or a specific interval? How does that impact data costs?
Do you already offer API endpoints for other partners? Are there any best practices or risks that you can learn from those? Do you need a separate API or can you reuse or extend existing features?
Maybe this is part of your requirement template, and yet - these are conversations worth having.
When in doubt: what’s the purpose?
When in doubt, come back to the purpose of the problem you are trying to solve. What is the minimum amount of data needed, the minimum amount of work required to get to a first version? How much context do your engineering colleagues need to make it happen? Perfect is literally the enemy of done. And as a Product Manager it’s your job to shape what “done” means like.
So, scratch perfection and get that first version in front of customers. Then you can start iterating based on real customer feedback and actual usage data.
This post was inspired by several discussions on how processes can (or cannot) shape human interaction. I’d love to hear your thoughts - reply to this email and you might spark another newsletter. And if you are looking for a mentor with a pragmatic approach, reach out via MentorCruise or get in touch directly.
Companies with an in-office history or time-zone aligned teams struggle with adopting asynchronous communication. Instead of wasting time getting rid of ALL the meetings, focus on optimizing important meetings to make “sync meetings” less necessary.