ProductWorld PRO Stage E
Monday, February 7, 2022
Is your team struggling with unproductive meetings and workshops? Are you unsatisfied with how your team comes together to refine requirements and specify solutions? Have you heard about example mapping and want to know more?
Specifying and delivering software is a process of discovery. No team has ever delivered a valuable product without discovering many things during the development process, but many teams struggle to get good at discovery. Matt Wynne created a technique called example mapping that has helped thousands of teams around the world use examples to reach a shared understanding of the problems that need solved. As a consequence there are fewer misunderstandings, fewer disagreements, and a smoother flow of value delivery.
Although leadership skills have been analyzed for so long, there is something in the way we choose and raise our technical leads that defy all laws. We often think that the brightest and most creative person in the team will eventually become a technical lead, which actually happens in most cases. The exciting part, though, the process of becoming a technical lead starts when we actually take over the role. What seemed to be a gratification for excellent results can become a long list of failures if you don’t really, really prepare for the challenge. Luckily we can learn from each other’s mistakes, so join us to touch some hot spots in the technical leadership journey.
The Agile Manifesto turned 20 this year, and while many of the core tenants are still applicable, the world has changed considerably in the last two decades. What would the Agile Manifesto look like if it was written today and took into consideration our new reality of hybrid working environments? Changes are most definitely needed, as software leaders find themselves still struggling to navigate the murky waters of 21st Century project management to get the most out of their team.
Developers’ complaints with Agile are myriad, but most of them come down to a lack of visibility and ownership. For example, developers can feel that frameworks like Scrum are nothing but bureaucracy, which is the opposite of its intended purpose. Developers can also feel disconnected from the bigger goals of their project, being trapped in an endless list of “to dos” without the time to think thoroughly about the features they’re creating.
As a project manager your most important job is to help your developers spend more time doing the work compared to tracking the work, while giving them the visibility they need to understand their progress. Using real world examples from some of the world’s largest software teams, this technical session will evaluate the new best practices that software development leaders are leveraging in order to get insights into their progress in real time, identify the blockers that are holding their team back, and secure the information they need to ensure they are helping their team to be their best.
Over the past 2 decades, interview methods for Product Managers evolved significantly. As we continue experimenting to find a truly accurate means of interviews, many tactics proven to have weak results have been dropped. Interestingly, with dramatic changes to the technology industry in recent years, resulting in both a surge of demand for PMs, and a surge in the supply, many companies unprepared for the new dynamics ended up with poor interview habits. Today, courses for PM interview training literally warn students that "being a good PM and interviewing for PM roles are not the same thing." It's time to re-assess our methods in this landscape, and in observing what we're doing wrong (and right), how to achieve a better process.
Here we'll share market data, learnings from many hiring managers over 5+ years, and learnings from PM interview courses to highlight quantitatively what is happening with our interviews.
Our organization's problem-solving approach has long been based off of Stanford's design thinking method or Google and Jake Knapp’s 5 day process from the book “Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days”. However, 5 day design sprints have had its challenges during the pandemic. We moved 100% remote due to Covid in 2020 and found it challenging to conduct a successful multi-day design sprint to solve key business problems. When already trying to push out as many high value features as possible in a saturated FinTech space, this became challenging and so we successfully created a hybrid approach and modified the process to just 2 hours.
2 hour design sprints help us deliver more value-driven features by simplifying the design thinking and design sprint process to our core business values in five stages - Empathize, Explore, Ideate, Prototype and Test. While still incorporating the spirit of Stanford’s design thinking process and the book “Sprint” we were able to condense our sessions to 2 hours which allowed us to include the right stakeholders, problem solve with our limited time, and have more positive outcomes and deliverables in designs to move into our agile sprints faster. Even better, we were able to have more design sprints in a month to solve multiple problems at a time by having the product managers lead the sessions.
Here are a few advantages and way to have a successful design sprint in 2 hours:
- Have your product manager or designer lead the session
- Simplify the problem you are trying to solve
- Use a collaborative tool for mapping ideas and rapid prototyping such as Figma or InVision
- And more...
PRO WORKSHOP: Building Better Product Culture: Why Extreme Programming (XP) Isn’t Just for Engineers
Extreme programming (XP) is a proven method for engineers to produce higher quality code and work better together. But what if I told you XP practices were the key to a better product culture for everyone? Some of the more well known practices of XP are pair programming and Test Driven Development (TDD), but what do they have to do with product management? It turns out that the values, principles, and practices of XP are deeply aligned with a lightweight approach to product management that creates strong, effective, and happy teams. And while these XP practices can be very powerful on their own, when combined with product practices that align around continuous improvement and iteration, the result is greater than the sum of its parts. This is good product culture: deep collaboration between engineering, design, and product to develop better solutions and enjoy the process. There are likely parts of your own practice that fit nicely into an XP-view of product management. Additionally, there are some concrete steps you can start taking today to get some of XP’s benefits by incorporating these practices into your own.