Lessons Learned: Don’t Over-Engineer

dont over engineer-01

A few weeks ago, I got a 570-word marketing email from the nonprofit organization that I support. Halfway through a scroll, I started to squint. After finishing the email, I scrolled back to the top and read it again. My eyes paused at the three bullet points about ⅓ the way down the email. They were thanking their donors for specific programs that were able to succeed. So why, why in the world was the beginning of the subject line “IMPORTANT” – yes, in all caps. What was so freaking important?

Boom. Found it.  Buried in the last paragraph was a non-bolded link in the middle of a sentence asking me to set up recurring giving. Well – I already have it set up – so what was the point? Probably because I’m “that guy” I replied quickly on my phone something I would say to my employees if they sent me this same email:

What’s the call to action here? I’m not sure it’s clear…

Yes, I’m probably being talked about…that Nate Strong. Ughhh. But the problem is that recently I’ve learned a valuable lesson from some product pivots we’ve been going through at Socedo. Don’t over-engineer. It sounds so simple! Just keep it simple.  But when you’re the expert in something, all you want to do is over-engineer.

I still remember it – we needed to create a way to block prospects from being engaged on social media twice through our application. We had found the problem and now we needed a solution. So we spent a whole two-week sprint to engineer a way for people to select how many days they wanted between duplicate engagements and giving the selection of what type of engagements to block. Nobody cared. They just wanted a check box where they could say “yes, I don’t want to duplicate engage with people.”

So I went away to Tanzania for 2.5 weeks. After flying back and hiking 5,800 vertical feet up Aasgard pass in the Cascade Mountains, I walked into work with a new perspective. Rip it all out. All of the complicated problems we were trying to solve with reporting that literally whole companies are selling individual products to solve – get rid of it.  That’s not our job to solve that problem, our job is to get customers the right leads that convert well. We’ll give them the KPI’s that we can control, and let them use the tools they’re already using to evaluate and modify the rest.

This is a dangerous prospect. I am passionate about our product and have helped to build some of the very features that I’m now telling our team to rip out.  We spent time (and therefore money) on building those features. But we have to see them as sunk costs and move on – let’s deliver what we need to deliver! Let’s be the experts at our product and not try to over-engineer.  It takes discipline. It takes asking the hard questions. And it requires you to remove your emotions from pushing forward on the product because trust me, you’ll want to make it the coolest technology! But most of the time, keeping it simple is better.

But it’s okay, I still give to that organization.

  2 comments for “Lessons Learned: Don’t Over-Engineer

  1. June 1, 2019 at 6:32 am

    En estos casos, generalmente, el problema no es duradero, y puede solucionarse a medida que los cónyuges se acostumbran y se sienten cómodos en la relación sexual. Sin embargo, la ansiedad de rendimiento es una de las causas psicológicas más comunes de impotencia, psicológicamente hablando se considera como un componente principal y persistente debido a su naturaleza autoperpetuante.

  2. June 5, 2019 at 10:20 am

    Cialis E Levitra Effetti Collaterali viagra Buy Viagara On Line In The Usa

Leave a Reply

Your email address will not be published. Required fields are marked *