You're reading the page one of the product development handbook.
Building software products
Making impactful digital products involves strategic thinking, good communication, and lots of collaboration. Product feature development is about figuring out the best way to elegantly solve problems within your team.
This guide is for you, if you want to:
Build products that all people want,
Make high-quality software, and
Make informed decisions during every step of the process.
What is product development?
Product development involves the process for researching, communicating, and building software products.
There are roughly 3 areas of work involved in product development.
Research - Discovery and validation of ideas. All research during the ideation phase and discovery have a cost but we invest in this cost to save money by not building the wrong thing. The goal of the research is to experiment and throw away some ideas and make calculated bets on others. If you aren't finding that some of your guesses were wrong - you probably are being too conservative with your guesses.
Documentation - Write things down and make it accessible. Write things down for people who may be trying to figure out 1 year from now, why a decision was made. Write things down for your teammates now so they know the full context to help inform their decisions.
Build - Build for longevity and include strategy and future thinking into your current architecture.
The product feature handbook is a resource on a process for making good software products - build a process and make it your own. It's good to keep an open-mind, iterate often, and find a strategy that intrinsically works for your team.
If you have any feedback for me the product feature development handbook or want to share strategies that work best for you email me at hey@ashlyn.app.
Why build products instead of projects?
Products and projects are not the same. Projects lend themselves very well to engineering or construction work like building a bridge or building a house. These types of projects have known design, known cost, are estimable, and have a defined end.
The complicated nature of solving unique problems when building software means that there are so many unknowns that it becomes too tricky to manage like a project. Projects have to be small enough to easily estimate the amount of effort required to complete. Anything with a medium amount of complexity or higher needs to be treated like a product.
Software projects try to have defined time-limits, fixed-budgets, and usually fixed-deliverables or scope-of-work. First, the budget is allocated to deliver a predefined scope of work, and when they have achieved their goal, the team will either disburse or work will transition to maintenance-mode. Or, the project will be considered over budget and the team will apply for more funding.
Projects usually follow waterfall or SCRUM methodology, where there's upfront solution design work, then it's estimated, then it gets built. A project manager's role is to constantly report on the timeline, risk, and likelihood of the team to meet their targets, which involves a lot of time spent on estimation exercises. Projects are not flexible, they are risky, they are very rarely successful. Projects more likely than not, never solve the problems that they are intended to solve.
If you manage your product like a project - you will fail. Statistically, you have about a 2.5% chance of delivering a project successfully. You are more likely to run out of money before you deliver. (source)
There are many other things that plague project development such as procurement processes, service level agreements, change requests, and estimations. Taking a product approach avoids many of the riskiest parts of software development, and focuses on delivering quality that achieves goals with longevity in mind. Having a product mindset means that the risk of solving problems with software is fully understood by all stakeholders.
More companies are hiring product people
Product roles are on the rise. There has been a steady rise of companies who have been taking a product mindset. And there is a shortage of product thinkers available to join product teams.
Project is out and product is in. There has been a 425% increase in the role of product managers in the past 5 years. (source)
Many teams or embracing a shift from deliverables, estimations, and resource allocation to focusing on outcomes, communication, quality, and efficiently. I advocate that every company that builds software products should have a Chief Product Officer or an equivalent product strategist at the board executive.
How to save money and time to meet your goals faster
You can save money and give more to your customer by taking a strategic approach to your feature development. Strategy and practice for feature development is probably the most important part of a software product company. The largest percentage of business outgoing expenses in product companies are staff expenditure.
Key areas contribute to cost of software:
Maintenance - the cost to support every line of code written, your infrastructure, fixing bugs, and reducing technical debt. For every new feature released, the cost of maintenance is increased.
Building new features - the cost of time across all decision-makers, researchers, and designers, developers, testers and other team members that bring a feature into production.
Research - knowing that you are achieving your goals and reducing risk during decision making.
Customer support - talking to your customers for any reason. When there is a miss-match in expectations of what your product does and expectations customer support costs increase considerably.
If you were to improve any one area of your business - improving how your team approaches building new features is the most direct way to reduce cost and achieve more of your goals. The process for building a new feature directly affects the maintenance of your product, research efficiency, and how much customer support you'll have to do. The easiest way to reduce cost across product delivery is to focus on how to you build new features.
When you deliver outputs and there is pressure to getting things out the door fast, it may feel counterintuitive to spend time researching, validating, communicating, testing, and documenting everything related to that feature. But spending effort building a feature that doesn't achieve the outcomes in the most efficient way will always cost you more money than putting more effort in the upfront.
Shifting effort to the front of the timeline for feature development helps to reduce risk and achieve more goals faster over a longer period of time. Outcomes for taking an ideal approach to feature development:
Reduce waste - increase in productivity of the team and get software in your customers' hands without cutting quality.
Build things people want - prioritise what you are going to build and keep stakeholder impact top of mind.
Optimise for success - make good decisions that are evidenced and the whole team can be accountable for. Be able to clearly articulate why you are building that feature.
Time optimisation may mean making a bigger upfront investment, to reduce the cost of long term costs. Without a solid process in a team, you can lose good ideas, and waste time, money and opportunity.
Working with features
The word feature may sound like a deliverable. Trust me, it's not. Features are a tool we can use to track and communicate solutions within our team. The word feature is just a name - features are solutions to problems.
When building software products: goals will change and priorities will shift. When we learn new information, we have to update our mental model, rethink our strategy, and incorporate our new learnings into our decision making.
Features are tangible. You can use features because they are focus point that your team can agree on. Features have clearly defined outputs. This handbook is a guide to product feature development. It is hard to explain just how having the sight of a tangible, visible, and singular object can bring focus and direction to your team. Features give people the ability to build momentum.
We build features to keep us focused on the outcome we are trying to achieve. The best vehicle for solving problems are through features.
In this handbook, you will learn the art of product feature development. It's how to define features in a way that help you communicate context, pick the right solution, and measure its success. A product feature is a single unit of value. By building features, you can follow the lifecycle from problem definition to the idea to achieving an outcome.
Functional vs non-functional features
A feature is usually as a single releasable unit or block of work that can add value for an end-user. Features usually represent new functionality being added to your app. There are two main types of features: functional, which adds new functionality that is visible to your end-user, or non-functional. With non-functional features, the end-user might not see any changes to the app. The feature delivers an outcome for other stakeholders such as the business, security, developer teams.
Deliver outcomes, not outputs
The feature is successfully delivered when you achieve the defined goal, not when the functionality is done. Features are directly linked to outcomes. They are not screens or pages. We build features, because they represent the end-to-end functionality needed to achieve an outcome.
With features, we care about: problems, outcomes, solutions, and goals. We want to avoid defining our features with screens, layouts, and pages. Because tracking screens creates noise, they are not the tangible thing that is easy to track if we are moving in the right directions. Screens or pages as a delivery tool lead to bike shedding, where people can argue over the trivial non-impactful aspects such as the colour a button is, instead of the bigger systems thinking. Focusing on managing outputs obfuscates the problem and solution.
And if you are thinking you can solve a problem in the most efficient way after high-fidelity mockups have been designed, your out of luck. It's more likely than not that the designer is already too emotionally connected to their design to feel comfortable throwing it away and going down another path to achieve the desired outcome in the most efficient way.
Product feature development is about figuring out the best way to elegantly solve problems within your team. This handbook will touch on the way that you can communicate across roles to comfortably stretch your thinking and optimise the things that matter the most.

go to next page

People and Roles

How do you get people working better together?
Like this handbook and want to see more?