When we approach the development of a new product we follow a specific workflow and some general guidelines, all ideas must be validated using this process before to decide if they are worth developing.
Guidelines
Product Management is not easy and it is costly: the last thing that we want is coding a MVP.
Product Management is not about coding and is not for geeks: Development will come at the end.
Act fast think fast: do not discuss too much details within validation process, we need to go fast.
Do not over-plan: "A good plan violently executed now is better then a perfect plan next week" (General George S. Patton) ...generals have hundred and hundred of years of experience in managing plans and teams, we might trust them.
Assumption, not intuition: You (probably) had a good intuition, but remember there already are a lot of guys doing the same in the world: the work will now be differentiating, the first storytelling that comes after the intuition is never the good one... your intuition? let's call it assumption.
Assumption, not opinion: You will never sell a product on the basis of your opinion, the best product is driven by customer needs. Opinions are forbidden, we need Data and measures.
Validation is mandatory, collect data and don't fall in love with your ideas.
Process to validate a product idea
We start always from the classical Business Model Canvas to map all aspects of our ideas and then we proceed iterating and validating our assumptions with a data driven approach involving technics like growth hacking.
This process will be executed by the Product Owner in collaboration with the Sales and Marketing team. The development team will act only in the MVP phase.
Logical Steps in the process are:
Concept: Understand the concept and the value proposition. All the following are mandatory:
- What is your target market? Is it broad or niche?
- You can have two main drivers that could be perceived from the customer: sell more or save cost. What is your product about? Remember that it's harder the "Sell more" option.
- What pain-point do you solve? Is it perceived as a pain from the customer or is it just a nice to have? All your target has the same perception? Customer won’t pay for a nice to have.
- Benchmark and find how your product is different (not in terms of price) from the competition. Write down features and differentiation points.
- Find the killer KSP (Key Selling Point).
- What is your business model? Is it Freeware or what? Remember that many customers want to touch the benefit before they buy.
- Do you have a price assumption in your mind?
- Do have any idea regarding how to name your product?
Value: Product pricing and revenues. It is really important to understand where is the value for the customer, the use case and the underlying ROI. If you don’t know these three components you are not validating the concept:
MEVO: A MEVO is a Minimum Economic Viable Offer which represents a prototype (UX or other, but NO CODING) of your concept. Avoid coding during the MEVO if it is possible.
Customer validation: We use growth hacking process for this because it is the most part of the activity and it is very easy to over-fit on a champion customer.
Product features validation: When you have the concept validated, you might validate the features:
- Never pitch the How, pitch the What
- Don’t think about selling: you are not on the customer to sell something, you are validating
- Ask advice to the customer
- Be severe on your features
- Validate assumptions
- Write down validations with a customer otherwise you won’t be able to share with the team and you will forget something important
- Validate features also with communities
- Avoid overselling and try to validate few features
Roadmap: Avoid plans, planning is better. Roadmap will evolve frequently, but it must be clear to all internal stakeholder and Sales must understand clearly where the value is
MVP
Customer Creation
We have an official template (Product Management - template) in the sharepoint "Products", to collect all the information in a structured way.
Key roles for Product development
Product development is an hard task that requires a strong alignment among engineering teams, product designing, product management, marketing and sales. Let's start from key roles description.
Product Manager
THere are several ways to define a product manager, but we like how Marty Cagan in his "Inspired" book is describing it.
Product manager should be a person with:
- deep knowledge of the customer
- deep knowledge of data
- deep knowledge of the company business
- deep knowledge of market and industry
- strong persistence and determination
The key responsibilities of a product manager are:
- evaluate opportunities and determine what gets built and delivered to customers: product backlog
The hard part is to understand and provide evidence that what is going into the backlog is really worth to building. When a product succeeds, it's because everyone on the team did what they needed to do. But when a product fails, it's the product manager's fault. That's the way of thinking we value to keep product managers accountable.
In addition to that is required to the product manager to share the product Vision and Strategy to the whole team and company.
Product Designer
Key responsibilities:
- Product discovery
- Holistic user experience design
- Prototyping
- User testing
- Interaction and visual design
Project Lead
This is our way to manage the overall delivery of the product. Project lead needs to coordinate tech leads/squad leads and in general the engineering team. Key responsibilities are:
- Estimate delivery scope, and deliver on time and on quality
- Orchestrate the conversion of the product backlog and roadmap in development tasks, managing the design of them
- People and head count management
Product Development Process
The overall lifecycle of the product should be handled with 2 weeks iterations.
Problems gathering
The product manager and eventually the forward deployed teams ( professional services ) should continuously collect information from the existing customers or potential ones. Pay attention that we don't want to collect features, but we want to collect problems. It is important to focus on problems instead of solutions, because problems are strictly linked with the value that we can deliver to the customers and we don't want to over-fit on solutions. Such information will be evaluated by the Project Manager, the Product Designer and the Engineering team to understand if it is worth to building and how to transform such problems in technical solutions and features.
Also the engineering team can be part of this bottom up process, because implementing the solution sometime it is easy to anticipate possible problems, mainly around processes and usability. When we anticipate problems we need to be sure to validate them with real customers.
The product manager typically is providing a Form that is accessible to the whole team where is possible to identify problems and suggest features.
Brainstorm meetings
This is a weekly meeting with the goal to work on backlog:
- understand features feasibility and complexity
- transform problems in feature opportunities ( checking the data collected by the Form )
- Discovery week planning
The whole team is participating in turning a collection of problems into a set of solutions and features. These features are still in the product backlog and not part of the roadmap. It is crucial to involve the whole team to feed their engagement and it is highly suggested to invite also other SME or stakeholders across the company (not part of the product team). During this phase is important to keep focus on business problems and solve them.
Discovery Week
In a product organization is super important to get evidence that we are building value for the customer and we are not destroying value for our company. A good feature has the following characteristics:
- is solving a real problem for the customer, ideally we should assess the customer willingness to pay for it
- is feasible from an engineering standpoint
- is sustainable within our business model
The product development process is all about learning, learning at 360°, and we need to be able to learn very fast. We need to understand the value and the feasibility of a feature for the customer before to implement it. Every four weeks, we spend one week for discovery purposes. It means that a part of the team for a full week will work on prototypes (MVP). The prototype should be actionable to validate the value for the customer. This means that the output of the discovery week must be validated in front of real users and customers.
Such MVP could be just a visual design or a real mock-up ot whatever is needed to assess value and feasibility, this is something that will be decided during the discovery week planning. These prototypes could be thrown away, but they should have strong learning effects for the whole team.
After validating the prototypes against users and customers, the product manager will understand if it is worth to building and in which phase of the roadmap should be delivered.
Discovery calls
A good product manager should frequently engage the customers and the potential ones to discuss about their problems and to validate the features prioritization. It is highly suggested to enlarge such meeting also to the engineering team, to let them have a better feeling about customer pains and feedbacks. During these discovery calls is also possible to test the prototypes that we built during the discovery week. Discovery calls should also happen at least with a monthly frequency.
Roadmap
We embrace outcome-based roadmap, and it means that the roadmap focuses on solving business problems instead of being just a list of features. We love this approach because it is really result oriented and it is aligned with other practices we adopt within the company, like OKR. The items of the roadmap have not due dates, we only group them based on their outcome and with a general timeline. We aware that up-front plans never work in our world, and also we want to be free to discover and learn new things along the path and change business priorities based on this. We rely on high integrity commitments and positive intents. The team is always doing its best to accomplish the goal, but in case it fails no drama, it is just another opportunity to learn something new about the process. Product management is about learn and discover, by definition an uncertain process, let's deal with that.
Our roadmap has always a key goal, something that we want to enable for the customer, and that is our North Star. It is totally useless to define a roadmap for more than a quarter, because product management it is simply too unpredictable and we don't want to loose the opportunity to bring great value and innovation for our customers, because we already promised a specific roadmap for the next 12 months.
After the team brainstorming and the discovery activities, the product manager is accountable to take the final decisions related to the roadmap and commit it with customers and stakeholders. The roadmap should be accessible to the whole team and it is important to notify the whole team when something is changing at that level (not at backlog level).
Feature Tracking
Product delivery is always a trade-off between being on time and being on quality. Sometimes, in order to generate value for the customer we need to take short-cuts from a technical standpoint. It is crucial that such trade-offs are reversible without any impact for the customer user experience. Working on complex products, with several modules and features, can become very challenging in terms of cognitive load. So it is recommended to adopt a feature tracking mechanism to trace what has been delivered. For each feature we track:
- technical debt
- design short-cuts
- improvements ( code, usability, etc )
- missing capabilities
In this way we can always understand where the technical debt is present and we don't need to remember it. Is a team duty to keep this up to date.
Quality
In the product team we need to aim for continuous improvement and this should reflect also on software quality, release management and internal processes ( teams communication ). We resume some of the pillars we value.
Definition Of Done
In the team must be super clear what is required to consider a feature Done: documentation, unit test, user tests, usability test, end to end, etc.
The team must work to keep each member accountable to this, no blame support, is just a matter of team priorities
Documentation
We want to be excellent in documentation and we value written form communication. A good way to do that is transforming conversations in documentation. For example the Product team should not explain a feature to the professional services through a hands-on session. If we need a face-to-face explanation, it means that the documentation is not clear enough. Instead of answering questions the product team improves the documentation.
Tech Debt
We know that technical debt could happen and will happen. We track and pro-actively address it. Pay attention that senior people in the ladder have specific accountabilities for that.
Guiding principles
At architecture level it is important to highlight which are the more important principles that we need to stick with. Those elements should be made super clear and available for the whole team in the High Level Design. All the team members when take low level design decisions must refer to them.
Software development workflow
In Agile Lab the software development lifecycle is highly standardized. Refer to Software Factory section.
Demo Environment
Our internal Demo environment should be managed as a production environment of the customer, and on this environment we apply continuous delivery principles. We are tracking the frequency, the consistency and the reliability of such delivery process.