Engineering to Product: A change of Focus

A wonderful trip from full time coders to part time product people

I’m Andrei, a tech guy — one of the three co-founders of socialinsider.io along with Adina, our marketing wiz and Razvan, a math geek.

When we got the idea to create socialinsider.io we couldn’t wait to get our hands deep into the code.

And so we did. Made a plan, drew an application flow and started typing away at the code. There’s something special about starting a coding project from scratch — the same clean sheet feeling you get when you start writing.

We were absolutely absorbed by the coding part and we totally loved it. After a few weeks of coding we had a working dashboard that felt like a good MVP for our product. We just had a few quirks to iron out. Or so we thought, soon enough we had a programming TODO list miles long and we’re figuring out how we can best manage the changes. On top of that tens of new feature ideas popped up every day and we wanted to include everything into our product.

The months got by, we launched our product. Mostly Adina did because we were too busy writing code to even feel like there’s something else to do.

We got users, a whole bunch of them and they started throwing suggestions and bug reports at us and something inside me just wanted to make everyone happy and just write all the code now.

We were not actually building a product, we were just writing code for the code’s sake.

And then it hit us — we were not actually building a product we were just writing code for the code’s sake. It might not seem at first, but keeping your head focused on having everything perfect was a rabbit hole. Add to that the fact that we always get ideas about new features — you get a dangerous cycle.

And it’s that cycle that keeps you mesmerised and feeling like you always have to code more. While it’s not a bad thing to want your application to have as few bugs as possible, it might prevent you from seeing the bigger picture.

Adina (who we thank for bearing with us) was periodically telling us to focus more on what’s important at the moment, growing our user-base or engaging more with the users we have. We weren’t really ready to hear that. We would always find time to create a new feature and never to look over our user personas.

Who are we building this for?

For me, the question that helped frame things better was “Who are we building this for?”. And then it hit us (me and Razvan) that spending all that time coding was not entirely helping our business grow. I might even go on a limb and say that it was an obstacle.

When we started “seeing the light”, things started looking a lot different. All of a sudden our horizon expanded a lot — there’s so much to do besides the code.

It can be overwhelming when you think about it, but it brings a lot of positive inner change. It also drives you to create a better product and experience for your users. It’s not that you suddenly stop coding, but rather refocus your efforts on what’s really important in the present.

Coding loses it’s magical aura — it’s no longer the silver bullet that solves all the problems. We become picky with what we code for and spend more time understanding our users better.

What can I do today to get the product forward the most?

It’s the question that drives us now. Sometimes we don’t know the right answer, but we start exploring.

Programmers program, marketers promote.

One would argue that it’s not the best way to spend our time: programmers program, marketers promote.

But when you don’t really need a programmer isn’t it a waste to have one full time?

And out of this refocusing we got a lot of small things going: an on-boarding mail campaign, social media promos, more content creation etc.

But the big thing we got was a change in objectives. It’s no longer “We have to deliver X and Y by next month”. It’s more centred on our business needs — “We need to grow our trial to paid conversion”. This can translate into some code improvements, but code is not the centre of our universe anymore.

We feel like we should have been doing these things from the start. Why wasn’t it obvious to us that this is what we needed to do? The only honest answer is that we were so busy building and improving the code that we couldn’t see beyond it.

Lessons learned

The pieces of advice I would have totally ignored when I was deep in code would be:

• Lift your head from the code from time to time, see what’s going on around you
• Stop building everything yourself, use prebuilt solutions — even if they’re not a perfect match
• Be a user of your product
• If you aren’t going to do it, nobody will do it for you
• Get time — delegate, automate, pay for tools if it gets you time

Liked this post? Be sure to follow socialinsider.io — a place for competitive analysis, Facebook insights, marketing and social brands.