Creating Vision post RIF

The journey to identifying a clear roadmap and vision for the future following a Reduction in Force.
Phase 1: Stabilize by focusing on short-term critical work
Following a layoff, a company can be left with gaps and issues that need to be addressed. Addressing these concerns is critical in order to keep tech and product operations up and running. The focus for the immediate short-term is to stabilize tech, design, and product operations. The following is a step-by-step way to ensure stability in unstable times.
Step 1: Inventory and Communication
Inventory:
Inventory of People: You will need an inventory of department resources left, and a people map so you can identify the relationships you will need to focus on. Any shift in ownership and responsibilities should be recognized and communicated to all stakeholders so that they may provide the correct support and expertise when needed.
Inventory of Systems: Determine Technology resource inventory and have a financial breakdown to assist with the costs for these different services.
Inventory of In Flight and Scheduled Projects: Look at all of the roadmaps for any of the teams under Design, Tech, or Product and assess the status of each. For those not complete identify the tasks needed to bring that project to completion.
Communication:
Establish Communication Channels: Transparency will be the most important thing for engineering, technology, and design moving forward. You will want to identify which communication channels should be utilized and which ones could be sunset. Possibly you may want to create and publish a repository where all product updates and activities can be discerned and recorded so external departments can keep track and have transparency.
Identify the Relationships that need to be prioritized and set up a Cadence for those Meetings: Determine the proper cross-functional meetings that should occur and book on a recurring basis. It is important to not let communication fall through the cracks at this time.
Step 2. Stabilize Infrastructure and Data
Once your inventory is identified you can go though and make sure everything is stable. Stabilizing technology is first. You need to ensure infrastructure is stable and that there are no outages and that data gathering is up and running so that issues or moments of irregular data can be caught. All the systems that could help catch and address any critical errors need to be operating smoothly and be monitored closely. So fix any infrastructure and backend pipeline issues to ensure reliability and good data flow. The last thing you want is for your services to crash and your team is unaware of where the problem occurred and unaware of the solution.
Stabilizing institutional knowledge is second. You need to address the knowledge gaps that come with the loss of resources and institutional knowledge. Those left at a company need to acquire the knowledge that previous employees may have been the key holders of. This can be a difficult case if people do not have the luxury to do informational interviews, but the hope is there has been enough documentation produced that institutional knowledge can be gathered straight from documents not people.
You need to address the knowledge gaps that come with the loss of resources and institutional knowledge.
Step 3. Cut your Losses
Inflight projects and work will be negatively impacted by loss of resources. You will be faced with determining which ones are close enough to be finished or if they should be abandoned for now. Product, Design, and Engineering should work through the Inventory of In-Flight and Scheduled Projects and identify what is actually feasible post rif. You have the inventory of all inflight projects from Step 1: Inventory and Communication. Once Tech and Product have come to an agreement on what’s feasible, they should present and discuss recommendations with the Executive team before rolling out any communications to the rest of the organization. The Executive team may have push back on certain decisions based on potential revenue forecast and contractually agreed upon items, and for that reason the Executive team’s decision will more likely be the final word.
Once work has been approved to be continued, tech can continue to try and deliver solutions but it should be known that timelines will inevitably be impacted and there should be more patience with tech and product resources at this time.
Phase 2: Adjust Course for the Long-term
Long-term future planning and collaborative problem-solving needs to be focused on the problems facing your company. It cannot be business as usual. After an industry lay off your priorities must shift. If they do not shift that is a good indicator that you may repeat previous mistakes. As always with layoffs, things will come down to financial impact. Although as a designer you will want to focus on the the users and advocate for them, this is a time where you may need to weigh you business’s financial health more to ensure that the business is around to provide their services to your customers. Phase 2 is focused on discovering the correct course of action to address the financial stability of your company. You must look at your company holistically and work cross-functionally to solve the problem that face everyone. By working together you can identify the projects that need priority and you will be able to create a new future roadmap and vision.
Step 1: Stakeholder Interviews
Hold Stakeholder Interviews with key members of your company. It’s important to understand each department’s problems, goals, and opportunities. During the interviews just take notes and try to extract as much data as possible. Make sure to dig deeper when members discuss their problems or goals by asking them “why” a few times to extract the root need or concern. Continue to prob and have them expand on their answers so you can walk away with a closer understanding to their knowedge. Sometimes stakeholders will keep things high level without going into much detail, it’s your job to uncover that detail so that you can use it in the next step. After data extraction, highlight the key takeaways by focus area and then summarize those takeaways. After that you want to synthesize all your data and group them into themes and identify trends.
I’ll provide an example of how this may play out. You meet with stakeholders from marketing, finance, sales, and technology. They provide a list of problems and opportunities. You extract and summarize that a few of the groups mentioned things around hitting the wrong markets and waiting too long to release important tech features. These are reoccurring problems, so you can make informed judgement that these problems face multiple departments and therefore are prevalent issues that you may want to look into. You basically take a bunch of 1 hour long interviews and you will walk away with your top 5-10 problems, goals, and opportunities.
Your task is to make sense and communicate out these findings to everyone so everyone is on the same page. It is not enough that you now know what everyone is thinking, the stakeholders you talked to and the rest of the company will all have interest in this information. Sharing this out will allow your company to build empathy across the different departments. You will have marketing saying “oh wow I didn’t know sales was going through the same thing”. And then people will begin to want to work together to solve these problems as they learn that they are not isolated instances that only impact them. Stakeholder interviews help lead to gaining more institutional knowledge and building empathy within your company. Communicating it out to everyone can be done in Step 3: System Alignment Kick Off.
Output: Key Takeaways and trends across departments.
Step 2: Data Discovery
If you have access to get data capture and analytics this is the time to look at it. Don’t just rely on what your coworkers, stakeholders, our your business execs think is going on. Look at the data! The data will tell you how users are interacting with your product. Which features they use the most. What areas or services are underutilized. From a design and business peerspective you don’t want to run into the scenario where you decide your next product roadmap around becoming a better “appointment booking tool” when really everyone just utilizes you for chat and not to book appointments. Yes, sometimes good design can influence changes in the habits of consumers, but more often you should identify the use cases, needs, and habits of your users and just enable those flows. If everyone comes to your app as a search engine and to look things up, why invest in note taking features unless you have proven that is a use case and a need of the users.
From your data you should be able to run through the entire user journey of your company experience and identify the areas that are successful, need improvement, or just not worth the investment anymore. You will uncover opportunities that may not have been obvious from just talking to stakeholders. Let your users speak for themselves through their actions. Let them tell you what they need and don’t need.
If you have the opportunity to, and the communication of the layoffs has not soured people away from talking to you, see if you can set up some user interviews. Choose to talk to existing users or identify the groups of people that you may want to attract as future clients. Talk to them, see what a day in the life is for them. See how your product or services can make an impact or enable their needs. Most often users are not going to try and tell you specific things that they want (Stakeholders do this too). But as designers and systems thinker it’s not your place to get fully formed ideas straight off the dinner plate. It’s your job to take that information in, ask why they say they want that, discover the true need, want, or problem, and then dig into the many ways that you could possibly solve for it. Don’t take things for face value. Investigate fur
Output: A data centric view into the end-to-end user experience.
Step 3: System Alignment Kick Off
Now that you have gathered all your data and have a good understanding of the problems and opportunities facing your company at this pivotal time, share that out with the rest of the company. Everyone needs to take the time and work together to discuss the problem. We need to meet cross-functionally to align on purpose and address the problem from a systems approach. Come together with stakeholders and present to them your findings. Then allow the group to discuss it and dig it to more. After people have ultimately digested what you presented to them, direct the conversation to prioritizing the issues. Ask them, “Okay of these five problems, which ones would have the biggest impact if we could fix them?”. You will have all the right people in the room who should provide input on what to prioritize. If there is some indecision on what the priorities should be, use an impact metric score. Have them rank the impact 1-5. Each group can make their own judgment on impact. Marketing may say “5” for something Tech may say “2”. Once you have all the impact scores find the average, and that is the true impact score of solving that problem. From here it should be pretty definitive which ones should be prioritized.
The most important part of this session is to not jump to solutionizing. That is not the purpose of the alignment session. The purpose of this session is to identify the most important problems to solve for according to key stakeholders. Solution ideation will come later when you involve the engineers and the teams that need to speak to feasibility, effort, and are probably closer to identifying tangible solutions to the problems.
Output: A list of 3-5 of the most impactful problems/opportunities to solve for.
Step 4: Problem Ideation Sessions
Alright. Now you see that you have taken the list of 10+ issues discussed from stakeholder interviews and have have identified your top 3 most impact problems/opportunities. Congrats! That’s huge. The second part of this system alignment now is “how can you solve for them?”. As the designer, you can facilitate an ideation session. Have an ideation session for each of the prioritized problems/opportunities. Discuss how might you may solve it and have everyone list whatever crazy ideas comes to mind down. After this take those ideas and place them on an impact vs effort matrix. This will give you a good idea of which solutions you may want to seriously consider pursuing. A lot of times the solutions or features previously discussed will fall into the high impact and high effort quadrant. This is not surprising as the people who push for these ideas typically don’t have a good grasp on the effort that is actually required. But the real gems will be the high impact, low effort solutions. This is always the sweet spot and the ones you (specifically your tech team) would like to see on the roadmap.
What’s also really import to note is that when it comes time for the ideation sessions, have at least one or more engineer, designer, and project manager present. In terms of owning the product roadmap these individuals are the ones who can speak to feasibility. A conversation on effort needs to include the team members who are actually subject matters on that effort, so don’t exclude them.
Output: A number of tech-approved, feasible solutions for each of the most impactful problems.
Step 5: Create Product Roadmap
After your ideation sessions you should have an initial idea of what solutions you may want to explore. What you don’t have are the designs, tech feasibility reviews, or any tickets created to actually break up the work. Until you know what the solution will actually look like, work like, and behave, tech cannot scope level of effort or communicate to stakeholders how long a project will take. So it falls back into the designers hands. Take the ideas that were discussed, sketch, create some lo-fi mocks, then get them in front of tech and stakeholders as soon as possible. Have them poke holes are your ideas and designs and go back and iterate on them. Do this until you guys have identified the right design solutions to move forward with. As a designer you may identify more work that had not been originally considered in the ideation sessions. This may force you to descope your solutions. Regardless, this is the part where Design can shine. You now have the power to really drive what the solutions for these problems will look like. Work closely with engineering until you guys have identified the feasible solutions.
Fun part, tech and design and product have all decided on designs and feel like they have a good idea of the vision forward. Now stop and go back and check in with your stakeholders. It’s important everyone is on board before anyone commits to doing work. Especially during the time post rif, stakeholders are going to want to be heavily involved in deciding what makes it to the product roadmap. Don’t let it frustrate you if you feel like it’s becoming a bit micromanaged. They have a lot of stake in the game to make this work, so their investment and participation should be welcomed. So get their approval, their input, and if need be go back and iterate some more. It’s crucial everyone is on board and part of the same team as you try to come back and gain momentum and success post rif.
Now that you guys have your feasible solutions, allow your engineers to take the time to break a part the work, look at how they may need to implement it, and let them create tickets to break up the work into tangible tasks. These tickets can then be assigned level of effort and time estimates. And that is how you will identify the timeline, or your future product roadmap. At this point you probably only have a clear idea of the solutions and work will be produced for the next quarter, and then have a high level idea of the problems that will be focused on for the rest of the year. It would be pretty unreasonable to try and have all solutions for the next year perfectly defined, because things change and you need to be flexible and prepared to react. If you have already committed to a feature roadmap a year in advance you are not taking into account that change is inevitable.
It would be pretty unreasonable to try and have all solutions for the next year perfectly defined, because things change and you need to be flexible and prepared to react. If you have already committed to a feature roadmap a year in advance you are not taking into account that change is inevitable.
Don’t paint yourself into a corner and say “Q3 of next year here are the 5 features that we will work on”. You will be holding your engineers and product team to an unfair rigid schedule and you will not account for the fact that priorities may change. Your product roadmap should reflect the situation of the company. It should be agile, pivot at certain points, and allow time to reevaluate and adjust course if needed. So feel comfortable communicating your first few projects, but beyond that leave yourself the room to once again stabilize and adjust course if needed.
Output: A short term product roadmap (possibly one quarter) and a long term list of problems you may want to include in your roadmap.