“If you don’t know where you’re going, any road will get you there”—Lewis Carroll
The
Software Development Life Cycle (SDLC)
describes the process for planning, designing, engineering, and releasing a software product or service. SDLC doesn’t exist to prescribe a strict process for building products, but rather illustrates a logical sequence of events that need to take place in order for a product to be considered done. As we’ll see later on, an iterative approach is ideal for software development when compared with a fixed, linear timeline. SDLC is widely understood and studied by major organizations as a top-level framework, and is split into six model phases (see Figure 3-1).
Figure 3-1.
The Six Model Phases
Being aware of the traditional SDLC concept is useful for a product manager, but the linear nature of the phases don’t lend themselves well to describing iterative software development (covered in a later chapter). Instead, we’ll step through an unstructured set of principles to keep in mind when going from product inception to polished end result that is consistent with the way products are developed at top-tier startups and tech firms.
Step 1: Ideation
Believe it or not, the idea is the simplest part of this entire journey. How many people do you know that utter the following phrase from time to time?
“I had the idea for [insert innovative product here] first. I should have followed through”
Before Uber existed, TaxiMagic and Hailo did the exact same thing. Instacart and AmazonFresh had a predecessor called WebVan that raised close to $400 million, but went bankrupt trying to do the same thing. The idea is just 1% of the equation; it doesn’t go anywhere without a ton of strategy, luck, focused decision-making, legwork, and clear execution that comes after it.
That said, if the core idea isn’t sound, it dooms the product (or startup) from the onset. An “Uber for Nachos” is a ridiculously dumb service, and there’s no amount of execution or capital in the world that can make it a success. When brainstorming new products to build, ask yourself the following questions:
- Is it useful?
- Does the world need this product?
- Does this product exist in the market already?
- If it exists, can we launch a version which is a 10x improvement?
- Is it feasible in terms of cost, time, and resources?
- Does it solve an existing problem?
- Why hasn’t the problem been solved already?
Everything you build should serve a purpose and alleviate the problem a user (consumer or enterprise) is facing. Otherwise, the product will end up quickly forgotten in the software graveyard shortly after launch.
Step 2: Create a product requirements document (PRD)
Once you have an idea, put it down on paper by creating a PRD. We’ll go through a PRD and how to create one in detail during the product strategy chapter, but in essence, it’s a document that describes the product, all of the features & requirements, and key details (timelines, risks, and so on). Start it off with a mission statement or core objective, follow up with the internals of the product, and finish with how you plan to execute on the vision. If the PRD is less than ten pages, it may not be thorough enough, so add as much detail as you can so all of the obvious questions anyone can ask are answered.
Step 3: Assemble the right team
Technical talent is underrated. Regardless of the salaries you see on Glassdoor or the fancy perks you hear about, people still treat engineers as an expendable resource. I can’t tell you how many times I’ve been to a tech mixer and hopeful entrepreneurs go around asking for free labor in exchange for 5 percent of their company, which is nothing more than an idea.
When assembling a team, align incentives. Everyone wants something at the end of the day: money, recognition, prestige, equity, and so on. If you’re a solo founder, find team members who are just as passionate about building something from the ground up. If you’re a product manager at a major organization, round up members who want to start a new business line and eject themselves from a team that incrementally moves the needle each year.
Tips for team dynamics
- Never prioritize talent over ego. No matter how skilled, ego will ruin the flow of the entire team.
- Establish credibility. People will be drawn to your team if they feel like you’re the right one to steer the ship.
- Be fair. Give credit where credit is due, and don’t overinflate your contribution.
- Have a diverse mix of skills, backgrounds, and viewpoints.
- Establish ground rules, set up one-on-ones, and allow room for team members to air their thoughts and concerns on a monthly basis.
Step 4: Create a Minimum Viable Product (MVP)
Software isn’t cheap to build if you’re working with a team of experienced developers. Costs can easily cross over the million-dollar threshold if it’s a technically complex product, so finding cheap ways to confirm that users want the product before investing all the chips at once is a smart thing to do.
That’s where MVPs come in. An MVP is a proof-of-concept first version of the product that doesn’t contain every feature on the wish list, but has enough functionality to be useable. For example, if you’re building a massively multiplayer video game, build just one world first and test with users before developing the others. Or, if you’re building a robot that delivers toothbrushes and toiletries to customers in a hotel, have one of your team members dress up in a convincing robot costume and have them deliver the item to the user. This may sound like a joke, but Star Wars has been using a human being to play R2-D2 instead of a mechanical robot, and Kenny Baker has done a pretty convincing job so far of making you believe it’s a real robot, right?
The user doesn’t know what’s missing and what’s been done intentionally. Using a bit of smoke and mirrors is okay if it prevents you from moving forward with a product nobody will use. In this phase, collect feedback from the user on the MVP, and note any changes, suggestions, or pain points that are immediately recognized.
Step 5: Establish product-market fit
Product-market fit, according to Marc Andreessen, means “being in a good market with a product that can satisfy that market.” In other words, find a market that’s sizeable enough to be interesting, then find the right product to disrupt the market. The easiest way to establish product-market fit is to rely on traditional metrics of success (revenue, user base, engagement, etc.), but what if you have a product that is still in the early stages?
Instead of using indicators or metrics that only come once the product is already successful, you can get creative with your approach.
Examples:
- Enterprise: for internal products, use a newsletter or group alias to drum up interest. Communicate the value proposition, then collect emails for follow up.
- Startup: create visual media and spin up a campaign on a crowdfunding website. If you can get orders before the product is fleshed out in the form of pre-orders, you’ll prove there’s a market for it.
The key takeaway from all of this is “don’t solve problems that don’t exist.”
Step 6: Don’t discount design
Design is a major driver of cash flow, but it’s often an afterthought in development environments. UX / UI designers are an additional expense to a team, and costs are cut in the design department to focus more on pumping out functionality. To illustrate the importance of design, let’s look at Hotel Tonight. As profiled in Fast Co. Design, Hotel Tonight was able to drive revenues up more than 10 percent by changing a simple confirmation logo. 10 percent! Users were accidentally booking non-refundable hotel rooms because their finger would slip and hit submit, and this resulted in a high cost to Hotel Tonight since they had to process a wave of customer service requests to correct the mistake on the side of the user. To remedy this, they decided to change to a checkout flow that involved the user tracing their finger over Hotel Tonight’s iconic bed logo. In this design, there is no possible way a user can accidentally book a room, and it saved Hotel Tonight time and customer service resources. Not to mention a sizeable annual revenue bump. Design is critical; treat it as such.
Step 7: Source feedback
The voice of the customer is always available to you in the form of feedback, but it’s a challenge to find the right way to capture it. As a product manager, you have to ask the right questions to mine the valuable info that can be fed back into the product. Surveys are a quick and dirty way to cast a wide net, but context is missed since you can’t ask follow-up questions in real time. Interviews are better, but they require a time tradeoff. Find the correct balance that works for you, and use the feedback to continue meeting the user’s needs. Problems and objectives can change over time, and becoming comfortable with the product at a fixed stage in its lifecycle is not a mindset that will lead to longevity.
Sample Q’s for the user
- What problem does this product solve?
- Do you use any other products along with this one to accomplish the same task?
- What can be improved? What is the product missing in your opinion?
- What would cause you to stop using the product?
- Is the product easy to use?
- What are the key strengths of the product?
- Would you recommend the product to others? Why or why not?
Step 8: Obsess over metrics
Track everything. Collect every shred of data that passes through your systems, then recognize the patterns that’ll lead to useful insights. A ton of users can tell you directly that they love your product, but if your monthly active user count is low, then the data tells a different story. Use the numbers from logs and analytics tools to corroborate the stories told by users in surveys or vocal feedback sessions. If there’s misalignment, then you’ve found the disconnect that needs further investigation.
Step 9: Win or Learn
After the end of all the steps, the product can still fail. You could develop an MVP and drum up support, only to be crushed when the final version is out on the market. Factors out of your control can cause the product to slip, but how you react and learn from the experience is completely within your control. If mistakes were made along the way, find ways to self-correct and adjust. If bad team members were chosen, make a mental note and promise never to repeat the same mistake. Everyone will have a bad product or two in their career. Whenever this is the case, spot the holes in the previous game plan and come back with the lessons next time around.