Effective Product Development operates in a quickly changing world with many unknowns. Our engineering and technical tools allow us to deliver value quickly by religion software quickly and often. We have proven frameworks that allow us to confidently deliver highly useful products in a landscape of uncertainty that allow business and product teams to change course rapidly as needed when user needs and market needs change. The framework I use is called AGILE and has been proven and trusted for ~20 years. We take an approach of aligning the organizational strategy and goals, identifying the correct people to build the product for and their needs, and delivering small incremental features iteratively and learning from them, before investing heavily in more robust versions. And, we always prioritize the most important work first, so we are always working on building the most valuable features. For every product there is a Why, a Who, a What, When and How. Below I describe in detail an agile approach to delivering work and how these pieces fit together. This process aligns the Why, Who, What, When and How- and at the end you get a useful product that your Business and Product teams can continue to improve and grow as your users’ needs grow and change.
When we solve the right problems for the right people (users) we create useful products that can succeeed.
Why does this product exist? For a product to succeed we want to make sure we are doing the right work for the right reason. Products that succeed build useful features that help users to fulfill a need or solve a problem so that they can accomplish something. First we must identify the purpose of the product and the reason the organization building the product exists. This is the strategic roadmap, similar to a mission statement, listing goals, what the product is supposed to do and the role it is supposed to fulfill for the users, ideally.
Who(m) is this product for? Products that succeed are products that solve a problem or a need for specific users. For a product to be successful you must build the right thing for the right user(s). So, we identify for whom we are solving this problem or fulfilling this need. These are your stakeholders and users. Users who get their needs met will continue to use your product because it is useful or helpful to them.
Now we know why we are here, and for whom we are building a thing for, what do we build? Once you know who you are building for, you look to understand their needs through identifying pain points and ways that the product could solve their problems and fulfill their needs. This is the “What” we will build. These will be our features, and can be thought of and written as user stories, “As a ‘User’, I want to ‘X- accomplish a thing’ so that I can ‘Y - solve some problem or get something done’.
- “As a person who desires information, I want to look up authoritative and true information, so I can inform myself and use the information for my research” or, “As a consumer of the Wikimedia API, I want to leverage search information, so I can display it on my website to my users so they dont leave my web property when they are looking for information. This makes my product and web property more valuable to them, and they will buy more stuff from me the longer they stay on my site”.
- “As a parent, I want to be able to book childcare from a trusted source conveniently and regularly.”
- “As a (wikipedia user), I want to see where the information referenced in this article came from, so that I can be sure that the sources are true, good and trusted.”
These statements allow us to make sure we are writing aligned goal oriented features that do something useful, to ensure we are not just building software to build stuff. These stories are the building blocks of your Product Roadmap, which I talk about next.
Once we have user stories, or the “what” we will build, we must decide when. And what to build first. This means prioritization. We want to prioritize initiatives (sets of related features) and features (items of work that provide value) in alignment with fulfilling the strategic goals, and based on what will provide the most value to the users. Remember, successful products successfully solve problems or provide value to users. This is called your Product Roadmap. It will be a prioritized list of initiatives and user stories/features, that describe the order that we will work on things. This roadmap is a living document, and will be revisited and updated frequently as things shift and as get user feedback on the features we’ve already delivered. It exists as a map for us to chart and navigate as the waters of our product’s usefulness unfold.
We will have to balance the users needs, the technical needs and dependencies of the platform along with any regulatory and security requirements. Once the initiatives and User Stories are prioritized we have a Product Roadmap that is aligned with the organization's strategic goals.
When will my feature be done? And how will we know when things will be done?- you might ask. We know that some of the work we are embarking on is new, thus we won't know exactly how long it takes. We can reasonably accurately estimate effort on small individual stories. So we will start there, with the highest priority work. This gives us a good idea of the next few weeks of work and how much we can get done. As we work as a team, our estimating will get better and better. The near term estimates will be the best, and the longer term estimates will be more rough but decent approximations. We can assure you however that we will always be working on the most important things first. This is how we prioritize, with the highest value items first, thus we will be able to tell you that the most important things will always be at the top of the work queue. If an item further down the roadmap becomes a higher priority we can move it up so that we work on and deliver it sooner.
Agiley. The product team, composed of product managers, architects, engineers and designers, will work in a series of “sprints” or time boxed efforts devoted to delivering value to users, by building specific features according to the roadmap and milestones developed previously. A sprint is usually a 1 or 2 week period.
The product engineers will estimate the near term work “user stories”, and the longer term work roughly, facilitated by the Product Manager(s). The Product Manager will manage the Product Roadmap and communicate estimates and updates to the various product stakeholders. The Product Manager will be the central point of communication for stakeholders and will manage and lead the product delivery team along with an Engineering Lead.
In each time boxed work effort, or “sprint” (1 or 2 weeks long), the product team will commit to and deliver working code and high priority features to the stakeholders for approval, and then to the users for use. For code submitted by volunteer engineers we can create a structured validation process whereby engineers working outside of the core teams submit code for review and inclusion by the core team based on the core teams release cadence. The Product Team will make sure that features/stories are small enough that they can easily be delivered by any engineering contributor, core team or volunteer contributor, to ensure work can be completed and delivered efficiently. Product Teams will strive to design user stories/features such that they are a smallest version of an idea/feature, so that we can get user feedback to validate the usefulness of the core idea of the feature before the team invests in building a larger version of it. There will be a structured quality check process that ensures code quality and feature completion before a feature can be released. The Product Manager and Engineering Lead are equally responsible for delivering a quality product.
Product Managers and or stakeholders will validate that features accomplish desired goals by testing them before approving them for release to users. Product Managers will then use a variety of tools to learn from users if the features are providing the desired value. When a feature is successful, the product team can then choose to enhance it. If a feature does not provide value, the team can modify it or work on something else that is more useful. Product Taams can also identify new issues and user needs by listening to users and getting frequent feedback.
This framework approach has many benefits. Here are a few: 1. The organization wont over invest in things that don’t work. 2. This approach helps to ensure the product works for users. 3. When the market changes, businesses and product development teams can respond quickly. 4. Users get new stuff often, and get to have a say in what they want and what works for them, which they like. 5. The team is always delivering the most important high value features 6. The team is consistently releasing useful software 7. The team is working in a realistic mode based on what we know and is realistic that there are things in the future that we don't know. Long gone are the days of building software where you design and build and have to wait a year or 2 to see if it works- to invest millions and find out the product doesn't suit the user’s needs. The world moves faster now, things change more quickly, and working this way means we can deliver a successful competitive product that responds quickly to users needs in a quickly evolving, changing landscape.
This is a high level overview of how Agile Product Teams can effective and efficiently deliver successful, mission aligned products. If there are more detailed questions, your Product Manager and Product Leadership can and will answer or address any questions or issues with the support of the product team along with the Organization's leadership if needed.