“Incremental innovation is basically just adjusting for inflation”—@BoredElonMusk twitter account
Innovation
is a term that penetrated the business and technology lexicon ages ago and still billed as the only way to stay relevant in the information age. New product entering the market? Innovative. Software update? Innovative. Slight refresh of a couple UI components? Innovative. When everything is labeled as being innovative, nothing really is.
Businesses forget that as they’re managing and developing in-house innovation hubs, other companies are doing the same. Absolute progress continues to move forward, but relative positioning stays exactly the same. The tech industry’s own version of the Red Queen’s race.
To compete in today’s markets, we need to chase disruptive innovation. The goal is to build products that become so deeply entrenched in our psyche and daily ability to function that we couldn’t have imagined life before without it. To do this, we need a strategy. In this chapter, we’ll examine ways to put together product documents, develop strategic plans, and touch on other considerations a product manager needs to be aware of in the scope of their project.
Forecasting the unknown
Legendary hockey player Wayne Gretzky was once quoted as saying “I skate to where the puck is going, not where it has been.” To paraphrase into a tech-relevant phrase, product managers need to “build for the future, not the present.” Software projects can range from six months at the low end all the way to 5+ years depending on the scope, complexity, and commitment.
With this in mind, how does the product manager forecast into the unknown and know where a user’s priorities will be years down the line?
The key is to pay attention to industry trends and integrate the cutting edge into aspects of the product being built. Today, machine learning, blockchain, and IoT are red hot, but the seasoned PM will know what is a fad destined to phase out in the near term and what can change the way products are developed five to ten years from now. Pay attention to the direction industry players are moving in, and pick and choose technologies that offer distinct advantages. Also, just because something hasn’t been done doesn’t mean it isn’t theoretically possible. Aim high and act ambitiously. The tech world is running out of room for more “Me-Too” products.
Budgeting & Estimation
When the CEO is putting together a budget proposal for the year, or new product development is scheduled to kick off, the recurring question that comes up is “how much do we need for product and engineering?”
For a new PM, it can be daunting and overwhelming to come up with a solid figure.
When assigning dollar figures to a proposal, keep in mind the following expenses:
- Labor (salaries)
- Software licenses (task management tools, source control, project management platforms, etc.)
- Hosting (cloud and bare metal servers)
- Equipment (computers and hardware)
- Open-source technologies
- Off-the-shelf technologies
- Third-party development
- Miscellaneous (travel, food, hotels)
- Training
- Development operations (penetration testing, moving from development to production, etc.)
Once an initial estimate is calculated, run it by the engineering managers, other product managers, and anyone else who has experience in this space. Everyone will have opinions, but if you reach a state where the estimates are all within an acceptable range, then you have your rough number.
Note
The number one rule to budgeting and estimation is to add a buffer. If the final figure is $1.2 million, add an additional 25% on top to offset unforeseen costs that can and will arise. Asking for more and having funds left over is always preferred to running out of money and stalling development until more budget is allocated.
Vendor management
Dealing with vendors can either be a headache or pleasure depending on who, what, and how much. At some point in your product career, you’ll have to either rely on a full-time dedicated vendor team to understand your creative vision, or supplement an internal workforce with outside talent to pick up tasks that the main team doesn’t have the time to execute. When sourcing a third-party vendor, you will come across tons of development shops (domestic and international) that want to bid for your budget. Finding a trusted vendor and establishing a long-term relationship is what every product manager hopes for, but in any case, it’s wise to remember a handful of guidelines when hiring contractors.
- Double check the SOW (Statement of Work): The SOW details what needs to be delivered, as well as the expenses associated with final handoff. Run the SOW by the legal team and ensure that your organization is protected in the event of unsuccessful completion. The SOW is the trusted handshake between two parties, so make sure everything about the project is included in this document.
- Fixed vs. variable cost: Some projects will be a fixed fee, others will vary based on time committed. Be sure not to assume that a variable price contract can’t go significantly above the agreed upon rate (hint: it can).
- Agile vs. waterfall: If the development team is using agile methodologies for software development, it can be tough to set an end date to the project. Don’t make recommendations to management that tie the team to a fixed month and day. Add buffer in the timeline and keep estimates to a 2–3 month window to be safe.
- Controlling scope: The SOW doesn’t list every feature and design requirement, so it’s essential to sit down with the vendor and use the PRD as a blueprint. Understand that scope will change throughout the project, and features can be added / dropped based on velocity and other considerations.
Studying the competition
Before starting a development cycle, the research phase will contain a competitive assessment stage. Spending time building a product only to find out later than a competitor with majority market share already exists is a bad way to go back to square one. To run a proper competitive assessment, tap into expert networks, pay research firms to pull information on market leaders in the space you’re targeting, and become a domain expert so you can spot the fakes from the real threats. A framework for modeling relationships in a delicate, competitive ecosystem that is widely referenced is
Porter’s 5 forces. The concept describes the forces that make an industry competitive or attractive based on the power position of incumbents. Using the five areas of focus and tailoring it to existing players can give a high-level view of opportunities and entry points, as shown in Figure 18-1.
Figure 18-1.
A high-level view of opportunities and entry points
Marketing 101
Let’s look at the basics of marketing.
The 4 Ps
A product manager is not a marketer, but they interface enough with the marketing manager
and team that terms and ideas will be picked up along the way. One ubiquitous tool for understanding product differentiators and the components of the overall marketing mix are the 4 Ps. The Ps are product, price, promotion, and place (see Figure 18-2). To use this model properly, consider drafting questions around each P and asking if your product has a satisfying answer. For example:
- Is the product priced competitively among the competition?
- Is the product readily available to purchase in areas with a concentration of target users?
- What is the proper channel to promote the product?
- What is the core differentiator of the product we are releasing?
Figure 18-2.
The 4 Ps
Marketing: Through the Lens
A concept that many people forget about is the promotion of their product. You can have an excellent product, but if you don’t put any marketing horsepower behind it, the results may vary. In 2014, I was working on a news aggregator app. During its initial launch, it was well received by users and downloads grew organically through word of mouth recommendations. However, it was not prioritized internally when it came to distribution of marketing spend. The company focused on promoting bigger bets, and this lead to the news app falling out of the trending apps and ultimately being sunsetted. A small percentage of products are so good that they essentially sell themselves, but if a user isn’t aware your product exists, they’ll have no option but to go with a close competitor.On the flip side, I’ve also seen examples of marketing being leveraged correctly to spark off user engagement at exponential rates. One of the products I’ve worked on in the fantasy sports and statistics domain managed to increase the user base in the order of millions of users per month by adding more money to the marketing budget. The effort was massive, and required all hands on deck, but the payoff was well worth it. Users were happy to use the product, and revenues justified the marketing bill. Without a marketing plan, the product’s potential would have remained under the surface for a long, long time.At the heart of it all, the product has to be good; there’s not enough marketing budget in the world that can substitute a product that solves a real issue. But, a product that solves a problem can get lost in the shuffle if it isn’t promoted properly. Hundreds (if not thousands) of apps, websites, and other software products are released daily, and you need a way to stand out in a sea of competition. Marketing can do this, and the uptick in user growth that comes with a dedicated marketing effort can be the X-factor for an impressive product launch.Sulman Haque, Sr. Business Planning Analyst at Oath (formerly known as Yahoo)
Go-to-market strategy
A go-to-market strategy
is the structured plan describing of all the marketing and promotional legwork required to reach customers and distribute the product to the wider audience. The go-to-market includes:
- The core value proposition
- Identification of target demographic
- Plans to reach the intended audience
- Factors of differentiation from industry leaders / competitors
- An overview of the marketing mix
- Brand positioning
- Establishing channels for promotion and awareness building
An overarching template for a go-to-market strategy doesn’t exist since it is tailored to the industry and company, but the development of this plan is advised because it mitigates reputational risk, enhances brand awareness, and shrinks the actual time to market for new product development. The marketing landscape is vast, and one company’s favored approach won’t work for another. For a product manager, your job is to sit in the room and align on the way the product is positioned to the customers and provide input on the strategic goals. In the end, the go-to-market will be aligned with the company’s product strategy and the two will go hand-in-hand to ensure a successful launch.
Product Requirements Document (PRD)
Writing a comprehensive, detailed PRD is a task that separates the good PMs from the high performers. The product requirements document is a manifest of all the features, requirements, and considerations identified before kicking off formal development. It communicates what a product should do, and the assumptions made prior to deeper analysis performed at later stages.
A proper PRD contains the following pieces of information:
- Header / Authorship: Title and names of all the authors (usually the product manager with contributors)
- Project Objectives / Goals: Purpose of the project, and the goals needed to be met once development is over.
- Scope: Describes the product, and specifically mentions out-of-scope requirements left for another version.
- High-Level Description: Short description of background / context, product information, and industry landscape.
- Stakeholders: All of the non-team members with a vested interest in project execution and success.
- Project Team: Lists titles, roles, and responsibilities of each member in the product development team.
- Product Overview: A longer, detailed view of the product discussing the key outcomes and features of this release.
- Functional Requirements: Requirements that describe what the product should do (e.g., the system sends an automatic email confirmation when a user is added)
- Non-functional Requirements: Requirements that describe how the product behaves (e.g., the product should have an uptime of 99.99%).
- Proposed Tech Stack: Runs through the software stack and the rationale behind chosen technologies.
- Timelines / Milestones: Estimated time window to completion along with pivotal milestones.
- Assumptions: Describes conditions which are thought to be true upon start of development.
- Risks / Constraints: Any and all risks that can throw the scope, budget, or timeline out of whack with mitigation plans for each. Also, constraints that limit development are included in this section.
- Future Development: Plans for the next version of the product and deferred feature sets.
- Open Questions: Unanswered queries that need to be clarified or closed out.
Product Roadmap
The roadmap is the living, breathing representation of the company’s product strategy. It communicates the now, next, and future development plans, and tracks the state of live products and their development paths. A roadmap can be represented as a thorough document, or mapped in a tool like ProdPad or Aha!
Here are the product roadmap goals:
- Measure progress against KPIs and trackable metrics
- Provide view on every product in the portfolio in one centralized place
- Secure buy-in from leadership and related stakeholders
- Tie product success to business goals
- Provide visibility for the internal teams to understand where the products are headed
- Rally around a unifying mission statement, and use this to direct decision-making
Use the roadmap to tell a story (an example is in Figure 18-3). Make it compelling and provide rationale for the set timelines. Granularity of information is based on personal preference, but enough detail to answer the pressing questions that come to mind for team members and leadership is enough to keep it live and active.
Figure 18-3.
Example Product Roadmap from ProductPlan
Conclusion
The specific techniques you develop early in your product career will become muscle memory after a couple of product deployments. Build good habits early, become comfortable with frequent documentation, and treat the artifacts you create as an extension of your verbally communicated vision. An organized PM with a clear strategy comforts the team and keeps leadership happy. And remember: there is enough randomness to the product role that at times, nobody knows what they’re doing. Fall back on what you know to be true, and stick to the plan :)