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.