When it comes to company intranets and collaboration platforms, many people have some scar tissue associated with the concept. So when I first encountered the team at Igloo, I was immediately interested in learning how they were tackling something that has, in the past, been a pain point for many. An intranet solution means different things to different teams, serves a wide range of purposes and above all has to be enjoyable to use. The team at Igloo has made that their mission. Igloo is a collaboration platform for teams both small and large with features like private blogs, file sharing, task management and company wikis. We spent an afternoon in February with the product team at Igloo to learn about the team’s structure and the way they approach product development.
Igloo is located in the heart of downtown Kitchener, in what was the former offices of a large Canadian bank. The team of close to 100 is located on the second floor. Matt and I took the elevator and landed outside the Igloo office, greeted by their front desk and honorary greeter-a mannequin named Norm. Norm is one of those things that starts as an inside joke in the office and just kind of sticks. We were greeted next by Marine Dumontier who works on the marketing team at Igloo. She explained that Norm was originally meant to keep the front desk company in their previous office and quickly became somewhat of a mascot. She added that before they shifted to more frequent product release cycles, he would often be dressed up based on the names of their major releases, like ‘Unicorn’ and ‘Viking’.
Moving past the entrance and into the office, the space was made up of two main open areas, connected by the kitchen and large glass board rooms. Along the edges of both spaces were smaller breakout rooms and desks were grouped in clusters based on the team. A white board near the support team read ‘Bug of the Month’, which Marine explained was where every month, the team would find both a very interesting bug in the insect world and an interesting bug in the software and talk about both. After the tour I met Michael Mackuliak, Igloo’s Director of Product Management to learn more about the product team and how they run their release cycles.
The product team at Igloo is made up of three product managers including Michael, and each product manager acts as a champion for one of Igloo’s three main roadmaps. Those three roadmaps, Michael explained are extensibility, enhancement and enterprise. Extensibility is how Igloo can integrate with other software their users rely on, with tools like Dropbox, Google and Slack. Enhancement is defined simply as how they can make the current product better, updates and improvements. Then the enterprise roadmap involves thinking about how they can scale the platform and architecture for larger organizations. Each product manager will make the case for why they think a feature in their roadmap should be prioritized for the upcoming cycle based on measuring it up against its impact to the product as whole. Things like what its impact will be on retaining customers, new revenue, and operational efficiency. Even though each product manager acts as the owner of their roadmap, together the team will take a holistic view at everything and decide what is priority.
From there the work will be defined as a product card, which Michael explained is a card where the idea will be scoped out and well-defined enough to be executed. He added that the team roughly tackles about five product cards per cycle, and they always end up being a blend of the three roadmaps. In addition to the product manager’s ideas, Igloo is continuously getting requests from users. Those end up becoming product cards as well and the team will use the same process for weighing those features, of course keeping in mind how frequently something has been requested. For example, if a feature is being highly requested, but doesn’t seem to score well against the current lens the product team is using, that helps the team reevaluate how they’re framing their thinking going forward.
“Build in five dollar bills. Don't try and take on doing a 20 dollar bill, because if you only get halfway, then you only have half of a 20 dollar bill and a product that is half-baked. This way you can deliver value incrementally.” —Michael
Once the team knows what features are going to be the focus for the next cycle, they’ll kick off the first of two 2-week sprints with a sprint planning session. This involves working closely with the development team to break each product card down into stories and deciding how much can be done in the first 2-week sprint. Every day there will be a stand-up to review progress that’s been made, remove roadblocks and make adjustments where needed. Each product manager assumes the role of a product owner and maintains a high-level view of the feature throughout the course of the 2-week sprints. Michael added that working this way, even for larger projects has allowed the team to deliver value incrementally throughout the process.
Previously Igloo was building and releasing updates in much longer time frames, so I talked with Joe Capka, the team’s VP of Tech about why they decided to make this change and how it came about. Joe manages the three directors that fall within the core product team: development, QA and product management (Michael’s team). Joe mentioned that for some time at Igloo there was a desire internally to move to a more agile process, but introducing new ways of working is always challenging and it can be difficult to determine where to start. After a lot of discussion, they decided to just dive in, starting small and introducing the sprint model. They reorganized the teams and developed three sprint teams made up of testers, developers and a product manager and experimented with running sprints.
“We thought about it for a while and then at one point it was just like all right, rip off the band-aid and go do it. So we started bottom-up in the sense of doing sprints.” —Joe
That worked great, but one of the main challenges was how they could apply this way of working to instances where the team needs to be more reactive, dealing with bugs and being able to put out fires. Joe elaborated on this, “if you commit to two weeks sprint, you really commit to doing this work and something comes up, it distracts you, it disrupts you and there goes your sprint.” The way they’ve mitigated this is by adding a “scramble” team. The scramble team deals with first in, first out work and are able to drop everything if something blows up. They’ll put in a tactical fix, recommend a strategic long-term fix, add it to the backlog and move on. It also gives team members flexibility in regards to what team they might be best suited for. Joe added, “it's a different type of individual, we have people that have been in both or people that prefer one over the other.”
Another challenge they discovered was translating the work done in sprints, up to longer term roadmaps. Joe explained the reality of having users and customers asking about long term plans for various features, or wanting to know when something would be built. The list can get long fast, and so finding a way to translate the work happening from daily standups, to sprints, and into quarterly or even yearly roadmaps was important. Joe added that this is something they continue to work on as a team but so far have at least been able to articulate what will be coming in the next cycle, and even the cycle after that. It’s a balance of being agile and being able to course correct, while still being able to keep a high-level view of the overall direction for the product. Joe illustrated that his role in this process is about being able to move between the 100,000 foot view, and 10,000 foot view. With his goals being quarterly, he’ll sit in on demos in the 2-week sprints and keep a high-level view of what’s happening within each monthly cycle, which will ideally translate to goals for that quarter. Which will then translate to various marketing efforts and other organization-wide efforts.
“We're still trying to figure that out, we have not cracked that nut but this is one way toward saying, "Okay well we can at least tell you what we're doing in the next cycle and we've locked it in and then what we're doing after that." It's an idea to commit but then be able to correct.” —Joe
Working within the three roadmaps helps to contextualize these high level goals, since their user base has such different interests and needs. Joe gave an example of their extensibility roadmap with being able to integrate with Dropbox, “is that enterprise? No it's not a need for scalability or performance anything like that. Is it an enhancement? Well sort of, but not really it's not the same as us adding features to our product, right?” He added that this helps with decision-making at a high level, looking at what is most important to them as a company at the moment. Joe explained that it might be really important to focus on enterprise for a cycle, which tells them they need to pick a little more from the enterprise roadmap at the sprint and release cycle level.
After chatting with both Michael and Joe, Matt and I toured around the office one last time. Someone whizzed by us on a hoverboard handing out paychecks, and we couldn’t resist embarrassing ourselves a little bit by trying out the hoverboards ourselves. The team at Igloo is all about creating software to make collaboration between teams easier, and so it was a bit meta to see how they themselves adjust and adapt as a team to collaborate more effectively. With so many different moving parts it was interesting to gain a little behind the scenes peek at how their product evolves on both a daily, micro scale and a more macro level.
Thanks to the team at Igloo for having us. They're currently looking for people to join their team!