Software in twice the time you expect
Software in twice the time you expect
"Everything Starts Out Looking Like a Toy" #91
Subscribe now to join smart, curious folks who get the Data Ops 📊 newsletter
Hi, I’m Greg 👋! I publish this newsletter on finding data products and interesting data observations with the goal of finding patterns and future product insights. (Also, it’s fun.) If you need a background on how we got here, check out What is Data Operations?
This week’s toy: a way to “use” a Mac from MacOS8 in your browser. It’s a pretty great simulation, combining software emulation with some clever UI. Now all I need to do is to find a ROM with Marble Madness on it and that will be some serious nostalgia. Edition 91 of this newsletter is here - it’s May 2, 2022.
The Big Idea
A short long-form essay about data things
⚙️ Software in twice the time you expect
What do the Mythical Man-Month, product management goals, and the typical software request by a prospect have in common? When you get into the details of discussing each one, they describe a process that takes much longer than anyone expects, and usually by a factor of two. Almost every software request (and product manager feature design) ends up consuming more time than originally designed.
You could call this scope creep, poor management, or even Parkinson’s Law: that projects expand to fill the time allotted for completion. Yet the ideas of cutting scope or changing the timeline feel like reactive ways to solve this problem. Why does it take a long time to build a feature request?
You need to know what you’re building
It sounds silly to say it out loud, but you need to know what you’re building at a pretty deep level. Most feature requests or bug reports start with a problem.
“When I did this, I observed something I didn’t expect.”
“I’d like to be able to do something that I can’t do today, and I think I do it really often”
“I just can’t figure this out and (this) works in other products.”
If you only describe one part of the problem, you won’t understand it fully. Observing a behavior only once? It may be an ephemeral problem. Seeing a thing happen twice may not be obvious to a user, and easy for a quality assistance developer to pinpoint when they look at the assumptions required by the software to paint an interface and deliver the right information to the user.
Take the parable of the blind men and the elephant in mind when thinking about this problem. When you see only one part of the system you are working on, you will have a specific solution for that item. And you also might not understand the implications for another team that is using your work. As a Product Manager, this means knowing what part of the “elephant” you are describing when you decide to create a feature.
One way to do this is to write a one-line statement of the benefit you want to create. For example, a search feature could be summarized as: “deliver the ability to type a single word and match against a list of items, returning the list of matches to that word, with the ability to jump from that match to the place where the word occurs.” Writing the story of the feature frees it from the potential constraints of the system and lets you focus on the benefit. But beware: if you propose flying cars and there are none, it will take much longer to get to a solution.
It may take several revisions or pictures drawn or conversations had to land on the appropriate brief statement to convey the accurate meaning or benefit of a feature. The reason this groundwork takes a bit to establish is that it’s usually the outcome of several other work items. The end product sounds simple because the rough edges to it have already been sanded down. The basic premise has been tested with several people, and there is an acknowledgment that the work product is possible and probable.
Turning the theoretical into the practical
Here are some of the questions you need to answer to build a better product brief. When fully realized, these items look like a complete Product Requirements Document. In practice, each organization is going to have a different version of these items to match the scope and seriousness of the development process and the feature desired.
You don’t need to do all of these things in order or fully. You need to know the answers to them to deliver a successful product vision for your idea. When you have answered these questions, you’ve removed a lot of the reasons that software development takes twice as long as you think.
This is by no means an exhaustive list and is a good place to get started whenever you are writing a feature definition. The end product need not be a book - but it does need to be in a format and time commitment that it gets done more often than not - and adjusted based on the size of the project. Whether it’s a slide deck, written document, or interpretive dance, you’ll need to answer questions like these to have a successful feature.
What is it? A concise description of the thing, along with any contextual information to identify it. If there are new terms and definitions that need to be introduced to describe this, call out that you will define them in context.
Why are we doing it? There needs to be a solid reason for undertaking this software effort. Is this a net new idea? Is it a fix for something that didn’t work out? Here’s a good place to share the “Why” and state a measurable benefit from this feature or idea.
What issues are we addressing and how do we plan to fix them? Expand on why we are doing to discuss the specific issues and a general approach for how to approach them. If we need to design or build new technology, you might also want to mention this here.
Are there any new terms and definitions? If you are introducing new concepts, you need to define them so that readers can place them within the idea of the whole application. If you are changing the meaning of existing terms or concepts, this is especially important to describe what changed.
How you will you split up the work? Creating a phased approach will help you to identify the most important work. Whether you want to explicitly limit the scope to a few items or set a level of work for “P1”, defining what needs to appear in the first version lets the team know when “done” is near.
What are the risks if we don’t get this done, and what benefits will we get if we get it done? It’s time to be very direct with yourself and the team. If this project doesn’t get done, what will happen? And if it does get done (according to the phases), what are the benefits you will get?
Why does it take twice as long as expected to complete a feature or a software project? One reason is that questions like this have not been fully answered. Another is that unexpected items often show up during the middle of designing and developing a feature that needs to be addressed.
Let’s look at an example to see how this might play out.
Putting the framework to a test
Most SaaS products need a search feature at some point, so let’s think about how the process of identifying the first search feature might work.
Using the simplified version of the above, we might create the following summary:
Why are we doing it? We’re building a search feature to help users find the things they are looking for when they are not on the same screen.
What issues are we addressing? Today, x% of users stay on the same page and y% experience only 2 pages. We want to enable users to see more than 3 pages in a session because we see that our most active users stick around longer and use the product more often.
Are there new terms and definitions? We want to introduce Searches - the queries that people use to find items – and Results, the result sets they get. By measuring where people click in the results and seeing if 1st page results (or top 5-10) result in longer sessions, we want to compare the sessions of people who search with people who don’t search.
How will the work be divided? We need to build a set of data that can be searched, an API service to query this data set, and a front end styling to present a search bar, a result set, and offer links to pages in the search result.
What are the risks and benefits? If we have a search index with too many items and no affordance for additional information, the user might not know which one to choose. In particular, we need to watch out for search results that appear to be identical because they have the same name. However, if we get this right, we will lower the time to task in helping the user reach the page they wanted. We’ll measure this by seeing if the overall time on app and the user satisfaction both go up over time.
It’s easy to feel that the version of an idea is the best one. “Let’s make it easier for users to find things - put a search box in the corner” It’s harder to say to a team: “let’s build a search experience that fits into our current product, creates a surface area that’s expandable, and makes sense as we develop new features and content.” Both viewpoints are needed. You will need to build predictably and show progress, but this can’t take forever. If your vision is too big, it needs to be cut down so that the team can build it in phases and tested as things go.
“Why don’t we just build?”
Many teams choose to “just build it” and fix it later. That’s one of the tradeoffs you could make. It’s also the cause of later delays where software refactoring or remodeling has to be done to fix what’s there. To borrow from the home remodeling process - eventually, you’ll need to bring it up to code.
If you want to build and design in tandem, this can be done too. Here are a few practices that help to co-develop software with an engineering team even when you don’t have a full product requirements document built.
Step 1: establish scope - and be exact
As a PM, you won’t be as exacting as a developer, but be as exact as you can be. Write down in simple terms what you expect, how the product should behave, and the results that you want to be achieved. It’s never a bad idea here to also suggest user behavior and their expectations. If you need help defining what you want the team to build, ask your friendly neighborhood developer. Involving them early is never a bad idea.
Step 2: document the ask and the plan
The minimum viable plan is to write the ask and the tasks in a single JIRA ticket, following a format where you are able to explain the present state (with pictures!) and paint the picture of the future idea (with pictures!). But get real. These asks are hardly ever as simple as writing a single task and getting the result that you need. The reality is that you need to come up with a format to state the problem, get feedback, answer and record the answers to questions, and get approval to proceed.
Step 3: communicate, communicate, and communicate
Getting your team members to participate in this process is the most important thing you could get from reading this essay. In a team of a few people, building a feature or an idea is not usually that controversial simply because there aren’t many people to disagree with your idea. As your team grows, the nodes in the network - and the likelihood of reaching people who disagree - demand that you improve the way you communicate.
Here’s a graph from the “Mythical Man Month” showing velocity decreasing as the group grows:
This is similar to the observation of “Two Pizza Teams” by Jeff Bezos and others at Amazon - there’s a practical limit to the amount of items any one team can understand deeply. But there is also an interlinked concept - these teams need to be able to not only get things done, but to share: what they are doing, how they did it, and how someone else can get up to speed.
Step 4: Getting it done and solving problems
There are many strategies for getting software work done. I prefer the simple. Tell people what you are going to do. Do it. Tell them that you did it.
Telling people what you are going to do is usually performed in a stand-up or another agile meeting. It doesn’t take long to complete and provides alignment, accountability, and raises blockers to the next level.
Just Do It. This doesn’t mean blindly completing work with no feedback. It means doing the work to the best of your ability, and raising your hand when you need help. You might need to make tradeoffs to get where you need to go. Understand why you might make those tradeoffs and you will be ahead of the game.
Finally, tell them that you did it. If you were creating content during the product development process, you will not only have an initial justification or product brief for your idea but also some pictures, recorded objections, and shared decisions made along the way.
Making a better process operational
If you’ve gotten to this point, you know that software development is incremental. We’re building the future, one step at a time.
What are some other solutions?
Sachi Rehkhi suggests a few in his essay on solving the mythical man-month: better communication, standards for development, smaller scope items, and overall excellence
John Foreman focuses on managing dependencies and introducing tools to help folks scale
What’s the takeaway? Software (and many other group projects that depend on communication with other humans) takes longer than you expect. Be as specific as possible about the problems you want to solve, but don’t wait too long to get feedback. Have frequent communication and simplify when things get slow. Raise your hand when you need feedback, and get really clear about which things you are going to solve and when to solve them.
Links for Reading and Sharing
These are links that caught my 👀
1/ On the network effects of Substack - Thomas Pueyo writes a fascinating summary of Substack and how they are building a different kind of marketplace. Unlike traditional marketplaces that try to monopolize the conversation (and the commerce) between buyer and supplier, Pueyo writes that Substack is creating something a lot more like a Saas solution for writers. By selling “pickaxes for miners”, Substack is creating audience-building tools for people who write, and a network of people who want to read their work.
2/ 103 important pieces of advice - Kevin Kelly (author of 1000 True Fans, among other things), shares 103 important pieces of advice he wishes he knew when he was young. This one hits particularly strongly: “Half the skill of being educated is learning what you can ignore.” This list is well-worn wisdom, and worth a read. Sometimes past you has a lot of good knowledge for future you.
3/ Data visualized at different ages - Who we spend time with changes over time. This in itself is not surprising. You don’t get unlimited time, and your living arrangements vary at different times of your life. The surprising thing to me is the time spent in mid life and later life with neighbors and acquaintances. We perceive that we spend most of our time with friends and families. The truth (and the data) looks a little different.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
I’m grateful you read this far. Thank you. If you found this useful, consider sharing with a friend.
Want more essays? Read on Data Operations or other writings at gregmeyer.com.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon