I’ve spent the last year or so in various stages of gutting my home; turning it from a bedsit with no central heating to a modern 1 bedroom flat/apartment that maintains its Victorian charm. Given that I’ve exhausted the pool of people at Kriya still willing to hear about the renovations, I thought I’d reach a new audience via our Tech blog 😆

Before and after

It’s still a work in progress but I’ve recently been reflecting on the experience now that I’ve moved back in. I’ve stressed, laughed and (almost positively) cried throughout the journey. A few highlights include learning:

• Who my friends are – thank you for letting me stay on your couch/floor/in your spare room for almost 4 months 🙌
• A new appreciation for building something from scratch – it somehow feels different when you’re doing it for yourself. I now have to look at that oddly placed switch everyday 😒
• Unexpectedly, how to be a better product manager👼

You may think that the last one’s a stretch, but let me share a few learnings that I’m bringing to my work as a product manager:

1. Challenge yourself and others to survive on less

Renovations: There were 6 versions of my flat MVP (Minimum Viable Product) – the absolute least I could do/pay for to make my home livable before I invested in ‘proper’ renovations. I kept asking: what can I do myself to save money or reduce the timeline? I completed round 1 of renovations (e.g. paint, carpet removal, new bathroom floors) myself, lived without a washing machine and sat on camp chairs for a year. All of this allowed me to reduce sunk costs and avoid making any big investments (e.g. a sofa) until I could visualise what I needed.

Kriya: When we were building our Business Loans product, I put all the ‘required’ features for the product on post-its. We held a few sessions where the teams involved would discuss and move the post-its above or below the ‘MVP line’. This was a great way to visualise what the MVP could look like. It also meant that 1) each team (e.g. Operations, Risk) could take away the post-its that didn’t make the cut and solve for them; and 2) the Tech team could prioritise those items before anything else. It’s very easy to get excited about future and new features before the fundamentals are working well!

The StoriesOnBoard tool we used to turn post-its into an MVP product roadmap

2. Over-communicate, even if it seems unnecessary at the time

Renovations: I agreed the position of a few lights with the contractors on-site but didn’t follow up in writing to the whole team. When I turned up two days later, they were incorrectly installed. Turns out there was some contractor churn and the spec didn’t get relayed, so the team lost a day changing the light positions. They weren’t particularly happy with me.

Kriya: As a Tech team, we’re trying to make a habit of circulating all background info, meeting notes etc. on project-specific Slack channels. That way, everything is documented and all stakeholders have visibility. On a recent project supporting our Risk team, my colleague Chris was sharing notes from a conversation with an engineer. A risk analyst also read the document and noticed a potential missing requirement. The team then came together to discuss and the item was added to the project, with the timelines adjusted accordingly. This is less about having the proof to call people out if something goes wrong, and more about giving everyone an opportunity to review and comment to ensure we’re all on the same page. It’s also tied to one of our company values, #1Team1Dream.

3. Plan for, but don’t accept, the ‘buffer’

Renovations: While I spent a lot of time documenting all requirements upfront, I did accept that at some point something would go wrong. One of those things was the kitchen cabinets. The initial proposal was to paint them on-site and push out the timeline by 2 days. Instead, I found someone to paint them off-site for the same price which allowed the project team to keep to schedule. It would have been easy to accept the 2 days but it really does add up as more and more small things creep in. Be tough!

Kriya: I’m not an engineer but, as a Tech team, we’ve become a lot better about spending more time preparing design documents and allocating delivery dates upfront. It’s really useful for stakeholders to know when new features will drop so they can prepare or amend processes. We’ve moved away from using traditional story points (abstract measurement of project complexity) to estimate project delivery. We found that over time we weren’t scoping projects as robustly as we should have because it’s easier to delay projects if you don’t commit to dates.

4. Most importantly, know when to step aside

Renovations: I would check in on progress daily, send emails with areas of concern and actively chase if I thought that something was wrong. It wasn’t until about halfway through the project that I realised my behaviour was actually counterproductive. I was micromanaging the build team instead of empowering them to carry out the project as per the detailed spec. I was also annoying them because I was ultimately challenging them on implementation methods when I had no experience in construction.

Kriya: If a project has been spec’d out properly, prioritised and kicked-off with all appropriate stakeholders, there isn’t too much value a product manager can bring to the table apart from unblocking if required. I’ve been co-owning (gathering requirements, discussing options, agreeing scope and deadlines with stakeholders) a recent project to support the Sales team with Mason, an engineer. But as soon as development started, I moved away and Mason is now owning the delivery. This not only creates cross-company project ownership, but also frees up my time (I used to spend 30-40% of my day in meetings) to focus on identifying the ‘Next Big Thing’ 😎

As we look to scale our Tech (Data, Design, Engineering and Product) team at Kriya, it’s really important that everyone in the company has the opportunity to be involved and that each of us is focused on what we do best. This will almost certainly result in the best outcomes for both our team and our customers.

I suppose my renovation experience means (sadly) that I shouldn’t pursue a career in construction…even though I look really cool with a facemask 😂