LookFar Labs20 January 2016

How to Have a Long and Happy Relationship with your Technical Partner

Development Doesn’t Have to be Stressful

Over the years, we have had the chance to work with some amazing companies and do some incredible things. Many of those projects have had us working closely with non-technical entrepreneurs.

This isn’t an easy position to be in for many founders. After all, we’re working on your baby, and it can be tough to figure out how you fit into the process when you can’t personally dive into the code we’re writing. Which brings us to the point of this blog.

Through our experiences with many different types of entrepreneurs, we have discovered there are some simple concepts that our partners can subscribe to which can drastically improve the success rate of a project.

You want a list, don’t you? Everyone likes lists. It’s the best candidate for “clickbaity” article titles: “Check out the Top 10 Top 10 Lists of 2015!!!!!”. Fine. Without further ado, here is a list of simple things non-technical founders can do to productively work with a software development team.

1. Communicate.

Phew. I feel pretty good about that list.

Oh, you wanted more?

Then let’s dig a bit deeper, but seriously – clear and honest communication is the cornerstone of all successful software development projects. Yes, that has been said time and time again, but there is a reason for that. Without clear communication through all phases of an implementation, any number of things can be its downfall.

Be passionate and knowledgeable

An entrepreneur who is passionate about her idea and knows what the hell she is talking about is exactly who LookFar wants to work with. When you feel it, we feel it, and the entire project will be much more enjoyable if the whole team is as pumped as you are. This is the starting point for how we decide who we want to work with on a project. If you don’t know your space and you aren’t passionately committed to turning your idea into reality, we may not be the partner you’re looking for.

If we do work together, get prepared. Do the research, listen to actual users, and learn to think like them. Always be thinking about the quickest way to test your idea in the market. We’ll do the same, and you will find it won’t always be necessary to actually have us build a feature out.

Have (at least some) money

Unfortunately, software development and maintenance is expensive. There are some cheaper options out there, but you get what you pay for. How often have you heard the story about the guy who got his app built by a bargain-price freelancer and was happy with what he got?

Yeah, me neither.

Our team is dedicated to finding cost-effective solutions that don’t sacrifice quality, innovation, and interesting product experiences. A team like that expects to be paid, and not just in coffee and free sandwiches.

If you do have money for software development, great! But the tech of your business isn’t the only thing you will need to fund. Make sure you are fundraising for all areas of your business to get it off the ground. Raising capital’s a topic for another day, but it’s enough to say that successful startups need to be able to budget for development, marketing, and other requirements for reaching their target market. We want our partners to be successful, so we love to see founders who are both realistic about the funding they need to launch and proactive about getting  it.

Be a partner, not a customer

It’s possible for development to work like this: you tell us what you want done, we go away for 2 months, then we deliver it to you and you pay us the monies.

Man, that sounds so impersonal.

When we say partner, there is an underlying need for trust that comes with that term. That’s why we use it to describe our relationship with those we work with. Projects fail when there is an imbalance in trust.

We’re in this together, so treat us like we’re working IN your company, not like we’re working FOR your company. We place a big emphasis on this one, and this small shift in thinking does wonders to help open collaboration produce meaningful results. Marriages only work if there is clear communication and trust, and the same goes for our relationship with our partners.

Buy into the process

From the moment you meet with our sales team to the moment we launch your product, we will guide you through a process that helps us learn who you are, what your idea is, and how we can get it tested in the market as quickly as possible.

Why bet the farm by building a bunch of features that you assume people will want when you can build a little and actually ask them? It’s this line of thinking that is at the center of how we approach software development, and it originates from the principles of Lean UX. We typically work in 2 week sprints, and you are very much a part of the agile process that we use to manage your project’s execution throughout the many build/measure/learn phases.

Participate in the process

From the get go, we provide you access to all the tools we use to manage your project so you can have constant visibility into what’s been done, what we’re currently doing, and where we’re going. Assumptions are bad. We like to stay on the same page as partners, and that only happens when you get in there and contribute to the process.

We also emphasize a short feedback loop from your target users, and while you are the subject matter expert of your domain, it’s impossible for you to think like every single user. Constantly gathering data from members of your target market is the only way to be sure you are always thinking about their behavior, wants, and needs.

Be responsive

From time to time, we will request things of you. Login credentials for various accounts, top secret files, the combination to your luggage – you know, typical things that arise in software development projects.

We’ll do our best to ask for these things before we need them, but it’s always best to get them sooner rather than later. Remember those kids in school that finished their book reports the night they were assigned? Those kids had their shit together, and they’d probably make good non-technical partners.

Tell us if you’re NOT happy, and tell us if you are.

We’re big boys and girls over here. We can take it. Our entire process is centered around giving you the best chance at success while keeping you excited throughout the entire project. If something isn’t working, tell us. The sooner you tell us, the faster we can address the issue to ensure the rest of your project goes off without a hitch.

On the flip side, if something is working, it’s always nice to hear when we’ve done something right. We like to hold start-stop-continue meetings to provide some reflection on whatever it is we’re retrospecting – a sprint, a project, a process. You can do the same for us; tell us what we should stop doing, what we need to start doing, and what we should keep doing.

We always look for ways to get better, and the people most qualified to tell us how to improve are our partners.

Help where you can

As I said earlier, software development is expensive, so we do our best to make sure you are investing smart money into your project. As such, if there is an area in the project where you can help out, do it!

No, I’m not saying to go learn UI/UX design and how to architect a well-structured API. That’s still definitely on us. But there are some things that inevitably arise during any project that you most certainly can handle without affecting our workflow. As an example, we had a partner take the initiative to research and obtain the data that would serve as the foundation for their prototype. They sourced and cleaned the data and sent it over to us in a format that was easy to import. Their effort on getting us the first data set gave us more time to invest into making the app kick ass. Just be sure to let us know what you plan on tackling.

See! I told you communication is the key to it all. Every one of those simple concepts revolve around it, and if everyone is always on the same page and working towards a common goal, we can do some amazing things.

Written by