In the software business, a lot of attention gets paid to “shipping” as a badge of honor if you want to be considered an innovator. Like any guiding philosophy, it’s best used as a general rule than as the primary yardstick by which you measure every individual decision. Agile, scrum, TDD, BDD — they’re all excellent practices to keep teams focused on results. After all, the longer you’re polishing your work and not putting it in the hands of users, the less you know about how they’ll be using it once you ship it!
These systems followed as gospel (particularly with larger projects or products) can lead to attention on the how rather than the what — thinking about the process as shipping “lines of code” or what text editor you’re using rather than useful results for users. Loops of user feedback are essential to building the right solution for the problem you’re addressing with your product.
Thinking more deeply about aligning the desires to both ship something rapidly while ensuring it aligns with product goals, it brings to mind a few questions to reflect on:
- What are you shipping?
- Is what you’re shipping actually useful to your user?
- How does the structure of your team impact your resulting product?
How can a team iterate and ship fast, while also delivering the product they’re promising to customers, that solves the expressed problem?
Defining product goals
To maintain a high iteration pace, goals must focus on outcomes, not the methods used. Begin by clearly defining success based on the specific problem you’re trying to solve. Harvard Business School professor Clayton Christensen created the Jobs-to-be-Done framework to aid this process. This framework helps businesses understand the connection between users and their reasons for using a product. Viewing your product through the “jobs” it performs for consumers clarifies the key problems to focus on solving.
Understanding users
On a similar thread as jobs-to-be-done, having a deep understanding of what the user is trying to achieve is essential in defining what to build.
This quote from the article gets to the heart of why it matters to understand with empathy what a user is trying to accomplish, it’s not always about our engineering-minded technical features or bells and whistles.
Jobs are never simply about function—they have powerful social and emotional dimensions.
The only way to unroll what’s driving a user is to have conversations and ask questions. Figure out the relationships between what the problem is and what they think the solution will be. Internally we talk a lot about this as “understanding pain.” People “hire” a product, tool, or person to reduce some sort of pain. Deep questioning to get to the root causes of pain is essential. Often times people want to self-prescribe their solution, which may not be ideal. Just look how often a patient browses WebMD, then goes to the doctor with a preconceived diagnosis.
On the flip side, product creators need to enter these conversations with an open mind, and avoid creating a solution looking for a problem. Doctors shouldn’t consult patients and make assumptions about the underlying causes of a patient’s symptoms! They’d be in for some serious legal trouble.
Organize the team to reflect goals
One of my favorite ideas in product development comes from Steven Sinofsky, former Microsoft product chief of Office and Windows:
”Don’t ship the org chart.”
The salient point being that companies have a tendency to create products that align with areas of responsibility within the company3. However, the user doesn’t care at all about the dividing lines within your company, only the resulting solutions you deliver.
Companies naturally start to resemble their customers over time. This trend is especially noticeable in federal contracting. Federal agencies tend to be large, slow-moving, and bureaucratic. Consequently, government contracting companies often mirror these traits in their products, services, and organizational structures.
We see three primary points to make sure our product fits the set of problems we’re solving for customers.
- For some, a toolbox. For small teams with focused problems, Fulcrum should be seamless to set up, purchase, and self-manage. Users should begin relieving their pains immediately.
- For others, a total solution. For large enterprises with diverse use cases and many stakeholders, Fulcrum can be set up as a total turnkey solution for the customer’s management team to administer. Our team of in-house experts consults with the customer for training and on-boarding, and the customer ends up with a full solution and the toolbox.
- Integrations as the glue. Customers large and small have systems of record and reporting requirements with which Fulcrum needs to integrate. Sometimes this is simple, sometimes very complex. But always the final outcome is a unique capability that can’t be had another way without building their own software from scratch.
Though we’re still a small team, we’ve tried to build up the functional areas around these objectives. As we advance the product and grow the team, it’s important to keep this in mind so that we’re still able to match our solution to customer problems.
For more on this topic, Sinofsky’s post on “Functional vs. Unit Organizations” analyzes the pros, cons, and trade offs of different org structures and the impacts on product. A great read.
Continued reflection, onward and upward 📈
In order to stay ahead of the curve and Always Be Shipping (the Right Product), it’s important to measure user results, constantly and honestly. The assumption should be that any feature could and should be improved, if we know enough from empirical evidence how we can make those improvements. With this sort of continuous reflection on the process, hopefully we’ll keep shipping the Right Product to our users.
- Christensen is most well known for his work on disruption theory. ↩
- Not to discount the value of team planning. It’s a crucial component of efficiency. My point is the clean Gantt chart on its own isn’t solving a customer problem! ↩
- Of course this problem is only minor in small companies. It’s of much greater concern to the Amazons and Microsofts of the world. ↩