14.8 Dev Intro 🎯
This section includes an Activity 🎯
Much of your time as a product manager will be spent working with your developers as they build the features and complete the stories that you created. Many issues will come up as they do their work—features that can't be built to specifications, technical challenges that need resolution, or personnel issues that threaten to derail your projects.
To collaborate successfully with your development team, you need to understand developers' day-to-day work. In this checkpoint, you'll learn about software developers' primary activities and responsibilities. With this information under your belt, you'll be better equipped to work with your team efficiently and effectively.
By the end of this checkpoint, you should be able to do the following:
- Explain the basic principles of software development
- Describe best practices for collaboration between developers and product managers
The development phase
Open Bootcamp provides a affordable Web dev bootcamp at webdevopen.com that you can try if you are keen on learning more about SWeb Development and Software engineering with a community
The first step of product development, which you focused on in previous modules, is discovery and research. In this process, the team refines and prioritizes their goals and tasks. After that, the product work shifts into the development, or implementation, phase. This is the phase in which the software engineering team develops the programs—in other words, writes the code—to integrate the features and user flows that were defined in the user stories (which are defined elsewhere in this program).
Development, in a sense, is like baking a cake. When you bake a cake, you have ingredients, a set of instructions, and probably a photo of the finished product. If you follow the instructions and use the right ingredients, you'll probably bake a cake that looks a lot like the one in the photo.
When it comes to development, product managers define the vision for "the cake"—down to who will buy it when it's done. They work with design teams to create mockups and user stories to illustrate what the finished product should look like and do. Then, developers write instructions a computer can follow to give those mockups life and turn them into functioning software. Ideally, the finished product matches the team's vision.
However, not every cake comes out exactly like the one in the photo. It takes creativity and improvisation to overcome problems that occur during the development process. Flexibility and innovative problem-solving are key to making your product vision a reality.
So, when does "cake-baking" begin and end? For organizations and teams that use agile and Scrum methods, development starts when a user story or feature requirement moves to the top of the product backlog and is assigned into a sprint (which is discussed in depth in another module). Development ends once the story is complete, which means the programming work has been tested by QA and validated by you or someone else on the product team. QA and validation processes allow the team to confirm that development and implementation were successful. The user story should match expectations and comply with general requirements—for instance, it should work on the product-supported browsers.
How computers work
The more you understand about how computers work—and how the program developers interact with them—the better you'll understand the product development process.
A computer is, quite literally, something that computes (in the past, the term computer actually applied to people who worked through complex calculations.) But it's important to distinguish between computing itself and the instructions being computed; this distinction is a key element of contemporary software development.
These instructions are the programs that developers write based on the stories and feature requirements given to them. A computer then processes the instructions it is provided.
Modern computers have allowed these instructions to become quite complex, and data can be input and/or output from those instructions. For instance, these instructions might involve inputting a file full of numbers and getting a sorted list as output. Or maybe they tell the computer to change an interface when a user hits a button or to output an API response based on a data input request submitted from another application.
Complex sets of instructions will often behave like a single large operation. They can be simple instructions, like "add two numbers and provide the result" or "move data from one location to another." A single instruction can also execute more complex processes, such as filtering and sorting large datasets or finding the most relevant results when there's no exact match in a list of results. The term algorithm is widely used to refer to the sets of instructions for solving specific requests. For instance, Google uses algorithms to execute and prioritize responses to a search. Similarly, a podcast-hosting site would use algorithms to recommend podcasts to a user based on what they've listened to in the past.
Developers must understand the problem their product is solving in order to create the best algorithm to address it. Of course, there are many possible solutions to a given problem—after all, data can be sorted in dozens of ways. Some methods are useful for sorting numbers; others are better for handling datasets with billions of diverse elements. And other methods are best for machines with very little memory. As a product manager, you'll need to work with your development team to identify optimal solutions. When developers have a clear understanding of the problem, the constraints, and what the solution needs to provide, they can determine the best algorithms for a product.
What do developers do with algorithms? They translate them into source code, which is the program written in a specific programming language. These programs use the APIs and other features of that programming language to enable the creation and enhancement of a feature in a way that addresses the user story. The combination of all the source code makes up an application.
But just like when you're baking a cake, things can go wrong when you're developing product features. For instance, the source code may have bugs in it. Bugs are any flaws that cause unexpected or incorrect results in an application. Bugs can be trivial, like a shape in a user interface that's not the right size on a specific browser. Or bugs can be serious—they might crash an application, leading to a user permanently losing their data.
This is why it's important to thoroughly test software. You'll want to make sure your product fulfills the user story requirements and test any changes to confirm that the new source code doesn't inadvertently create an issue when it interacts with the application's existing code.
The video below provides an amazing insight into the Product Development Process at Google
The job of a developer
You've learned a lot about what it means to work with a software developer. But what does their day-to-day look like? A software developer's most important responsibilities are to write, debug, and test the software that runs the applications for a product. They do this by writing source code in programming languages. This code is packaged into applications that provide the features and experiences of a product.
However, developers actually do much more than that. They work intimately with design, product, and infrastructure teams. Together, they determine the best solutions to address user story requirements and solve any issues that arise during implementation. For example, imagine your team is developing a search engine for an e-commerce product. In this case, the developers would have many discussions with the infrastructure team about database capabilities. If the database was too slow, the developers would involve product management and the design team to modify the user workflow and minimize the effect of the slow database. Or they may come up with a different solution, like a change in user flow that reduces demand on the database.
Developers also spend time designing the solutions for the stories they're working on. Before they write any code, they'll break a story down and plan the work needed to implement a solution. By planning before they start programming, developers can speed up the programming process and often identify issues before they've invested a lot of time and effort.
Development teams often delegate work based on area of specialty. Frontend developers work on aspects of the user interface, websites, mobile apps, and other user-facing features. Backend developers work on the APIs and hidden processes that handle data exchanges between servers. And infrastructure engineers work on the databases, networks, and storage systems that underlie the backend services.
Developers also have different responsibilities based on experience and seniority. Most developers are individual contributors who spend most of their time writing programs. These developers have titles like software engineer or senior software engineer. More senior developers—with titles like lead engineer, engineering architect, or director of engineering—oversee the technical work of the team. With their teams, these developers design the high-level interactivity of new programs, determining how the programs will work together and with the existing stack. These individuals also manage the implementation of this high-level design and review their developers' program designs to ensure everything will work together.
Depending on the size of an organization, a lead engineer may be responsible for several teams. These teams may work on different products within a suite of tools, or they may focus on different areas of the technology stack. The most senior member of an engineering team manages the directors or leads, oversees the overall product architecture, and works with the other department executives to run the company. They have titles like engineering director, vice president of engineering, or chief technology officer (CTO).
When it comes to product management, you'll interact with some developers more than others. Product managers often work with individual developers and lead engineers on the specifics of feature implementation. But they also work with engineering management to ensure that projects are properly staffed, to get feedback on early roadmap planning, and to solve problems during development. In larger organizations, an individual product manager is unlikely to work directly with top-level engineering executives. These executives would likely sign off on their teams' involvement in projects and help resolve issues that have been escalated to upper management.
A developer's typical day
In many organizations, developers start their workday with a stand-up meeting (sometimes also referred to as a morning roll call or daily Scrum). These types of meetings are typical to agile development and are discussed in depth in another module. The idea behind the name is that the meeting is done standing up, which prevents it from becoming lengthy. These meetings are usually timeboxed to 10-15 minutes.
In a stand-up meeting, the team discusses which tasks have been completed since the last stand-up, which tasks will be worked on that day, and any problems that need attention. After that, most developers will shift their focus to their programming tasks—in other words, they will develop the software that makes a product work. Their tasks might include programming for stories in progress and preparing for upcoming user stories. If they can't figure out the answer to a question, they will likely raise the issue at the next day's stand-up meeting.
Sometimes, developers are assigned to work on design documents, testing features or other small tasks. If there is an urgent fix that must be made, like a serious bug in the code, a developer will resolve the issue. Occasionally, this means a developer will shift all their attention toward troubleshooting and away from their user story work. But for most organizations, the goal is to have developers spend most of their time building software.
Best practices: PM and dev collaboration
As a product manager, it's absolutely essential that you establish a good working relationship with your development team. In some organizations, this relationship can be adversarial, which leads to a whole host of problems. Just a few miscommunications and misunderstandings can create a challenging dynamic between product management and development. It's important for every member of both teams to be well-prepared, focus on working together, promote a sense of shared product ownership, and respect the expertise of others. Using these guiding principles, you can create and contribute to a productive and positive team culture.
Many of the issues you'll encounter on the job are recurring; in fact, you can probably prepare for them. Think about what your developer needs and provide them with what they need to succeed. By identifying your colleagues' likely questions ahead of time, you can unblock potential obstacles to their progress and increase the likelihood that development work will be completed as you envisioned. Plus, the developers will respect and enjoy working with you more.
Reinforce the why
Many development teams are treated like feature factories. Their colleagues ask them to crank out user story after user story and offer them minimal insight into why they're doing that work. As a product manager, you should share the why with your development team. Why is a user story important? How will it benefit users? Be sure to provide examples, too. By providing this information, you can show your team where the product is going, explain why certain priorities have been set, and highlight how and why the developers' work matters. Once provided with this insight and transparency, your developers may offer up great ideas for slightly different approaches that more effectively accomplish your goals. If that happens, listen to them. Likewise, let developers know how recent launches have succeeded or failed. This will give them a better sense of how they can contribute and make them more personally invested in the product's success.
Review developer designs and early versions
Working on software projects is like a game of telephone: a task that seems clear during one conversation may get translated incorrectly when the information is passed along. As a product manager, you have the difficult job of preventing these mistranslations—you must ensure that the developers' plans and end results match what you and your design team intended.
Many development teams write technical documentation to communicate and document how a feature will be built. You should take the time to review this documentation. You may not understand all the technical details, but it shows respect for the developers' work and allows you to ask questions and confirm that their specifications are consistent with the enhancement you envision. It's also important to test their work in progress. This demonstrates your investment in their process, ensures everyone that the work is on the right track, and provides you with an opportunity to flag and address any inconsistencies early on.
Determine time estimates and scope work
When planning upcoming enhancements and roadmaps, you'll work with developers to estimate the time and effort required. Some features may take a long time to develop or have extreme development risks, like when introducing a new technology or integrating with a third party's API. As a product manager, you'll be under pressure to release features quickly. But it's important for you to establish a balance. Work with your development team to identify and mitigate any risks, and manage stakeholder expectations to prevent the development team from being put in a challenging situation. Collaborate with your team to find solutions that provide new features in a fast, but low-risk way.
Scope changes
In the middle of developing a feature, your developers will likely face an unexpected issue that dramatically expands the scope of work. Maybe the team was overoptimistic about what it would take to implement a new technology, or maybe management suddenly demands a new requirement that derails all the work that's already been done. Or maybe a new test reveals that users don't understand how to use the feature, so a significant redesign is needed. Scope changes are inevitable. In these cases, it is your job to work with your team to come up with efficient strategies for handling the changes.
At some point, you will also experience a similar series of changes known as scope creep. Scope creep reflects the fact that over time, making many small tweaks to the original project adds up. Not only does the team lose track of the original goals, but this creep expands scope and delays—or prevents—the launch of new enhancements. Be wary of scope creep by focusing on the MVP of the feature and pushing to get that launched.
Perform quality assurance testing
Product managers typically determine whether or not a feature is done. And quality assurance (QA) is the process they use to make this determination. QA testing is usually run by a team—often called the QA team, which you'll learn more about later—within the engineering department. But ultimately, the product manager is responsible for what is launched.
Ideally, features are thoroughly tested before they're released. Stakeholders should see the work and confirm that the feature is working as expected, and you (as the PM) should be confident that it's ready for market. Sometimes, there will be significant pressure to meet a target launch date. As a product manager, you should know if the work is on track and testing looks good. You should probably play around with the product yourself. If you have concerns, be prepared to raise them with management and provide possible solutions.
Keeping your devs in flow
Like most professionals, engineering teams work best when they're in flow—a state of uninterrupted focus in which they're wholly engrossed in their work. Whenever someone interrupts a developer—to ask a question, discuss a bug, or outline scope changes—their flow is disrupted. It is in your best interest to fiercely protect your development team from these interruptions. After all, when you're doing work that demands concentration, you probably avoid distractions, too. By being a gatekeeper for your development team, you can help them stay on track.
And do watch this too, if you're planning on building your own product and company at some point in your life.
Activity 🎯
Reach out to a developer. This could be a friend or family member, a LinkedIn contact, someone you met at a hackathon or other networking event, or even a PMcademy member you found via a local or general-discussion Slack channel.
Ask for 10-15 minutes of their time for a quick conversation; you can think of this as a kind of cross-functional informational interview. (In fact, if you can, do it with someone who works for a company you may be interested in working for. It's a great way to network.)
Prepare three to four questions to ask them; these could be about the day-to-day of their job as developers or about their collaborations with product teams. You could ask them about good and bad experiences they've had or for their best advice for a new PM. Write a short summary of your questions, their answers, and your biggest takeaways from the conversation in your doc or Notion Page.