I’ve noticed that some organizations come to Atomic Object with a short-term project, while others come with a longer-term vision around a product they want to create. When an organization thinks about work in terms of a project, it’s usually focused on delivery and output. When an organization thinks about work in terms of a product, it’s usually focused on solving a problem for users without knowing exactly what that solution is.
Understanding this difference can help organizations plan team structures, set budgets, and think about how to continuously update products to achieve different kinds of business goals.
When Custom Software Is a “Project”
There are a few characteristics that I see in organizations that see their software as a project.
They have a finite list of work.
These projects are focused on accomplishing a list of work items (e.g., an overhaul of the user interface or a specific set of new features).
Often, this list of work is based on what the CEO wants or what others at the company have been able to lobby for without validation and research. Sometimes, the list has been generated in response to one or two complaints online. Occasionally, the list is based on meaningful user feedback, user research, or significant metrics that have been evaluated to drive the company forward.
They have fixed funding.
These projects are typically funded for a fixed amount of time with a temporary team (e.g., a team of two developers for four months). This may seem like a great way to get a little bit of work done quickly and cheaply. But in reality, this approach rarely considers the time a development team spends onboarding to an existing codebase, understanding or writing underlying architecture, and learning new programming languages. It also doesn’t allow the team to think deeply about users and the business as they are simply “executing” someone else’s request.
They have an unclear vision.
These projects often require agreement from various stakeholders. If the stakeholders came together to create the list of work without considering the larger product ecosystem, they often end up debating features, since each stakeholder feels that “their” requested work is the most important. This often stalls development on an already time-sensitive engagement or can lead to churn as work is prioritized again and again. This also can create a poor experience for stakeholders who learn they won’t get everything they want.
When Custom Software Is a “Product”
There are a few characteristics that I see in clients or companies who view software as a product.
They discover what to build.
The team works to collect and understand quantitative and qualitative data to inform their decisions about what to work on. This data may come from user research, customer surveys, or competitive analysis. It may also come from analytics both within the software (completion time, retention, number of clicks), or analytics outside the software (device purchases or application downloads, statistics from the marketing team). This team understands the product itself, as well as the product and market ecosystems, and how they affect the product’s end-users.
This is different from a project-based approach, where the development team just builds things that internal stakeholder(s) have decided will be valuable to users.
They provide continued support for development.
The team is staffed and funded until the product is someday shut down. The process of discovering what to build to solve a need in the market should continue until that need has been satisfied and/or additional opportunities are presented.
The important thing to look for is if the client is thinking about the technical and product support for the entire shelf-life of their product, or just using this engagement to “build the product” or “add some features.” A product is a living piece of software that will need care and tending in order to continue growing to success.
The team is empowered.
Having a longer-term team that understands the data and product goals has a number of benefits. First off, the team is empowered to make educated decisions about the product and can evaluate technical and design solutions through the lens of the end consumer and overall product success. This gives the team the knowledge to make decisions about the most important work to complete.
In addition, understanding the data and having a longer-term vision of the product aligns the team and the client, leading to a common understanding of the priority of features and their timeline. This improves the client relationship, as well as strengthening the final product that is designed and developed.
As consultants, we can’t always be around until the end of the project. Instead, we work with the client to find the best short-term solution for their product in the long-term. This often includes pairing closely with in-house developers, providing options for maintenance contracts, and in some cases, helping staff up client teams to ensure the project can be supported until the product is complete. In addition, it’s important that we discuss organizational changes that will support product thinking as a way of organizing around the software that is built.
Which Is Better?
A project-based approach can work well in certain situations, such as moving from one delivery system to another, upgrading infrastructure components, or for moving a manual process to an automated system.
Product-based thinking can be helpful when considering questions like, how can we recruit and retain users of our app or software? How can we use technology to deliver meaningful recommendations to users? Or how can we make it easier for humans to find a thing (content, item, etc.) that they need or want?
When I see the signs of a client thinking about the second set of questions as a project, I like to talk about the idea of a product-based approach, which will be discussed more in a future post.