Rosie and Rob have both been to conferences recently, so decided to make that the jumping off point for this episode of The Product Shipping Forecast. As well as litigating whether conferences are really worth it... They also talk about the other ways they try to make sure they’re continuing to learn and develop.

Despite our best intentions, it’s sometimes a fact of product development that not every feature is a hit. So what happens when you release a flop? On this episode of The Product Shipping Forecast, Rosie and Rob reflect on the features that weren’t successes and what they’ve learned from the experience.

Working on a product for any length of time will reveal all the little feature requests and improvements that could delight users, but they very rarely get prioritized over other work. In this episode, Rosie and Rob talk about how their team embraced Small but Mighty features alongside their larger product work and what they’ve learned along the way. What makes a good Small but Mighty feature? Can a feature get too big? And how might other teams adopt this practice?

A solid user research practice is the basis for many of the great products we use everyday, but it sometimes feels like an uphill battle just to get time for usability testing. How can you better advocate for research in your company? What can you do to make research a regular part of the process? Rosie and Rob have the key insights on episode three of The Product Shipping Forecast.

In an ideal world, QA should be a simple step to check the quality and functionality of what a team is about to ship. Yet, all too often, it’s a grab bag of compromises, disappointments, and UX polish tickets that will be left to linger in developer backlogs like unwanted house guests. How did it get this way, and how can you make QA a little less painful?

For the first episode of The Product Shipping Forecast, Rosie and Rob dive into the deep end of the product development process to discuss handoff. They discuss the tools and practices that have helped—and hindered—their transition from designing to building. Is there such a thing as too much documentation? Can a single tool solve your handoff woes? And what does “ready for dev” mean in a world of agile and Kanban workflows?