Few things I learned at a startup and implemented at Microsoft

Henn Ruukel is a Group Engineering Manager at Microsoft. They provide Fraud and Spam prevention services for Microsoft calling and messaging features across the products (Skype, Teams, Azure Communications Services). Before joining Microsoft, Henn spent seven years building his own startup – Fleep – with a mission to radically improve how people manage their work conversations, tasks, and emails. Henn has also been part of Veriff’s product team, being the CPO.
Henn shared with us his learnings from the startup years. The lessons have stayed with him in Microsoft. He believes that people should cultivate their thinking rather than implement-once-and-forget processes. Constant reminding and practicing help the lessons become invisible thought patterns.

Start with “Why?”

I am a huge fan of Simon Sinek’s “Golden Circle” concept where the main essence for me as an engineer is that as we are solution-oriented by profession, we tend to jump directly into “What?” and “How?” in our thinking, communications, and ideations. Engineers tend to jump directly into questions “What?” and “How?”. Yet, we easily forget to cover the question “Why?”. That is usually the motivation behind this initiative why the company is investing in it. The company needs to be aligned within the team and with the customer on why we are doing this. It may sound like a simple question, but it is easy to overlook it. If the team doesn't know why they are doing it, how could they proceed to what and how?

Who is the customer? What problem are we trying to solve?

Clarity around the target customer and clarity on a particular problem the team is trying to solve is something every product manager needs to provide. Although this is a basic concept of product management, I have to admit I have not been clear enough myself on this as a co-founder in my startup. Neither can I say we always have clarity on this here in Microsoft. As product managers, we have a natural tendency to jump in assumptions and over-generalize use-cases and target audiences. That leads to solutions that are either too big to implement. Or have a too wide audience to validate the fit for the solution. It also makes it harder to set clear metrics for the validation of the success.

To strive towards clarity on these topics, I have found peer-pressure in the product team working quite efficiently and reflections from the engineers to be a good validation whether this clarity is provided or not. Also splitting ideas into as small deliverables as possible de-risks the implementation and provides faster validation of the success.

Discovery versus implementation workstreams

Discovery and implementation – two parallel workstreams I've implemented from the book “Inspired”.

In the discovery phase, our focus is on validating as quickly and cheaply as possible whether we have understood customer problems correctly and whether the solution(s) we have in mind actually work and solve that problem in the most efficient way. So talking to customers, building prototypes, and testing these is what is being done in this workstream. Although it is Product Managers lead and work heavy workstream, the whole team is included. Quite often, (throw-away) code is built and launched to validate the idea with the target audience.
Failing here is cheap, even if we throw away what we had built and start again from the beginning.

However, the implementation phase starts as soon as the discovery phase has produced validations. Not necessarily to the whole scope, but to a sizeable part of the scope. In this phase, we know why we are doing something. What is the scope, and how to implement it. Investment wise in this phase, everything is built “properly” following all the compliance, localization, code coverage, and other principles, so we don’t want to experiment here. Here, we build things we know are working and solving customer problems. Failing here is expensive and should be avoided.

This concept helps to avoid investing too much too early into something, where we don’t know yet, if we have understood the actual problem and whether we have the right solution in mind. Separating discovery into separate workstreams helps to avoid feature-creep and overinvestments too early.

This concept is a journey, not a destination. Over the last few years, I've seen a lot of good progress in introducing it to the team. Nevertheless, I believe that our team still has room for improvement going forward. This is an exhaustive list rather than things I’d call out as a good concept to start from.

Microsoft is a partner of sTARTUp Day 2021! Check out the two seminars by Microsoft taking place on August 27 – "Lessons learned from Skype – handling fraud in consumer paid products" and "How we've built the best scalable work culture in Estonia". In addition, Mihkel Rembel, Startup Manager at Microsoft will conquer the stage on August 27.
Articles you might also like:

Madis Lehtmets, New Program Manager: “Design is a problem-solving methodology”

Madis Lehtmets is the new Program Manager of sTARTUp Day! We talked with him about design, startups, stand-up comedy, how to write...
Read more

President Alar Karis at sTARTUp Day — “The Future of Innovation in Estonia”

We asked for sTARTUp Day 2024 visitor feedback, with one of the questions being about the most memorable speaker. The most popular...
Read more