Before I left in 2016 I documented the approach we used for building successful products for future Managers on the team. BrightRoll Product Themes to Consider For New Initiatives Whenever thinking about new initiatives, it’s important to keep a few guiding principles in mind from the very beginning of the planning phase. 1. Be Data Driven This one is a bit cheesy and may seem obvious, but its importance cannot be stressed enough. Using data to make informed decisions and to stitch together your story for how and why to accomplish certain tasks is invaluable. The Hackers* are an incredibly valuable asset to help make this happen. *We were fortunate to have a group of incredibly smart and talented engineers/data scientists on the Product team to assist with complex analyses and R&D projects. 2. Involve Engineering in Design Discussions It’s easy to make assumptions on how or why to do certain things, but without Engineering’s buy-in and participation in design, these initiatives become much more difficult. The more Engineering can learn about the business and your Product vision and strategy, the easier your job as a PM becomes. 3. Get Feedback Early and Often Democratizing ideas and seeking feedback on your approach will only make your life easier. Initiatives and Products that received feedback from stakeholders other than the PO are consistently more comprehensive, more scalable, and more successful. Distribute user stories to other PMs, Hackers, Engineering, Business reps, and UX to receive a diverse set of feedback that can be incorporated (or not) into the Product story. Lifecycle of a Product Initiative This should not be taken as gospel. Everything listed here are ideas and suggestions, and should serve as a guide to reference when developing new products and initiatives. 1. Idea Maybe you have your own ideas about features, optimizations, or products that need to happen or get built — that’s fine. Make sure to prioritize these accordingly, against everything else on your backlog. Talk to the relevant customers, business teams, Engineering, and other PMs about gaps in your product, and determine what makes the most sense to do in what order. 2. Research Use data and talk to stakeholders to define the requirements of the initiative. Whiteboards and peers are helpful sounding boards to bounce ideas off of when struggling to think through a complex problem. Do research outside of the company, if relevant. Find out how competitors are approaching these problems, and identify gaps in their solutions. 3. Epics, User Stories, and Backlogs WRITE STUFF DOWN. This one is incredibly important. There is more to do than time permits — this will always be the case. The only realistic method of not letting good ideas slip through the cracks is by . Whether that consists of a personal backlog that isn’t shared with anyone, a simple to-do list, or a proper / more organized backlog, always writing stuff down write stuff down. But also, keep a reasonably updated backlog. This can be a challenging step to follow, but it is crucial to help craft and deliver a solid Product vision. Engineers love well formed (and deep) backlogs so they always have work to do, and it provides ammo to Product when approaching initiatives in an iterative fashion ( ). “this is the MVP, but the next phase is on the backlog…” Put together a basic user story for every initiative. Other than very small one-off tasks, Product documentation should be a requirement. This provides PMs an opportunity to get their thoughts on “paper” and make their assumptions known, while also stating the requirements very clearly. With good user stories, PMs are able to share docs with stakeholders (UX, Hackers, business reps), instead of attending meetings. 4. Prioritization At the end of the day, only so much can get done. If the team is focused on X, they cannot work on Y. There will always be trade-offs (even when other parts of the company might refuse to accept this fact…), and Product / Engineering will never get done. everything As a result, being able to quickly make decisions about which tasks, initiatives, features, and services are higher priority is critical. Ignore the low priority stuff (or at least bump it to the bottom of your to-do list), and focus on the important things. Make these decisions quickly, but make sure to seek feedback from peers or managers if the right answer isn’t clear. 5. Engineering Assessment While PMs can make educated guesses on the level of effort required to accomplish certain initiatives, they should seek the advice and feedback of Engineering. Ask Senior Engineering and Eng Management if they think technical design docs are required (often a good idea, but can add time to a project). Make a best effort of breaking large initiatives into phases, but work with Engineering to assess to proper technical pathway. Product should focus on answering the question, “how can we deliver value as quickly as possible, and iterate on a given feature or service to optimize its efficacy?”. Develop a plan, but be comfortable straying from the plan and being flexible when changes arise. Credit: http://blog.crisp.se/2014/10/08/henrikkniberg/what-is-scrum 6. Agile Approach If you take the example of building a car, avoid thinking about the phases as (1) building a wheel, (2) then the axle, (3) then the frame of the car, and (4) finally a fully working car. Instead, think about how to deliver as much value as possible, as quickly as possible. When there are optimizations that you identify, think about how to approach those optimizations in an iterative approach. You’ll almost never get it all right on the first try (but don’t let that stop you from trying to) — expect to need follow-ups and optimizations. Credit: http://blog.crisp.se/2014/10/08/henrikkniberg/what-is-scrum 7. Product Review In the later years of BrightRoll, we started doing Product Reviews — the audience would typically involve some combination of Product and Engineering Leadership, relevant representatives from the business, Product Marketing, and possibly our CEO. This step may not always occur, and it might take place in a different sequence than where it sits in this list, but it’s an important and helpful practice to help with a number of things — (1) forces the PM to think through the whole story of what we’re building, (2) why we’re building it, (3) why we’re building it , and (4) what we should expect to see and measure upon release. like this Additionally, sometimes defining what we are building is even more important than what we are. The Product Review process serves as the PM’s opportunity to clearly outline what the stakeholders should expect, and what they should expect. not not Product Reviews are also great opportunities for PMs to show off what they and their team have done, and get in front of upper management to talk about their respective product areas. 8. Planning Now that the user story is done, feedback has been received and incorporated, the initiative has been properly prioritized, and Engineering has gotten a chance to weigh in on the implementation approach, it’s time to actually break this into tasks and plan it into the sprint. Work with Engineering to determine how to break this work into tasks (this might involve creating Jira tickets, or using some other tool, depending on how the scrum team uses sprint boards). Some engineers encourage PMs to create the actual tickets, others prefer to do this themselves. During the planning process, bring as many tickets into the sprint as the team is comfortable committing to, in a single sprint. 9. Go-To-Market and Product Release Process Loop in Product Marketing as early as possible (ideally before development begins). Working with Product Marketing and the relevant business reps from the idea or prioritization stage will help to offload a lot of the communication and coordination to alert teams about the new changes, and to train them if applicable. By looping in these teams ahead of time, their chances of having a positive impact on the outcome of an initiative are greatly increased. 10. Tracking the Impact and Measuring the Results Is the feature working? How do you know? What data can you leverage the demonstrate the story? Work with the Hackers, BI, other PMs, etc, to ensure we know whether or not a feature is working, and what the impact is. This is crucial for delivering a successful initiative, end to end. The project cannot be called complete if we can’t definitively point to the impact / success (or failure). Major hat tip to and for acting as phenomenal mentors and Product leaders during my time at BrightRoll and Yahoo. Tom Schmidt Pravin Savkar Part 2 on best practices for communicating product updates is coming soon. — Danny Roosevelt (say hi at ) danny@dannyroosevelt.com

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Product Process (part 1)

Too Long; Didn't Read

People Mentioned

Danny Roosevelt

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Product Process (part 1)

Too Long; Didn't Read

People Mentioned

Danny Roosevelt

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES