Pushing Your Client To Be The Best

A few weeks ago, my boss and I visited a Meetup at the Vincent Benjamin building that my recruiter friend throws. I actually spoke at this Meetup back in August. The focus of the Meetup is on the more startup oriented businesses As a contracting company this can slippery territory for us. Carine Dieude spoke at this event about the number one ticket an investor is looking for in an app is traction.

Part of what makes my company Iced Dev so great is that we have always have had empathy for our clients. We also love when our code actually ships! That's why when I was at the meetup event, I wanted to talk about the topic of shippable code.

Often times when working with clients we see them start to go down the "well we need this" path...which is fine. It's probably a good idea as an expectant of development services to allocate more resources than what you get a quote for. This will help in case of a worst case scenario, or you need to implement extra features to make your product viable on the market. A lot of times developers just miss on quotes(that's why we're so reluctant to give them out).

We have seen some masterful pivots, remove and replace features while still maintaining core functionality, and staying in line with a Statement of Work from your developers is a hard task...But that is a job for the Startup Owner, as developers we do what you say, it's your company after all!

As a developer it should be our goal to steer our clients towards shipment, but never to force their hand. This can be a fine balance to walk sometimes. That's why I'm writing this article! Keeping your product ready to go for a tangible reachable goal is important! Always be ready to have a plan of action if you need to change to make a situation work.

As a member of a startup that perhaps has hired the services of developers for your app, or your API, consider the risks involved before the commencement of your project cycle! When going into a project try to think of "Five for Five".....

What five features might we add, OR we might need to add to get this product launched?

Versus

What Five Features can I drop if worst comes to worst, or I need to shift features?

Either way, by keeping these aces in the hole, we are allotting flexibility and maintaining our ability to keep product viability during the development cycle.

Risk Management comes into play at this point. As both the developer, and the startup, knowing these five options on each side can help build a VERY reachable goal. The developer knows what they can work around, and what they can perhaps remove if needed.

The good news is, if you finish on time, neither of these have to be utilized, and they can be added to your second iteration's Kanban board(insert methodology of choice here). If you finish early, maybe you can snag a feature and add it quickly if your developer recommends it.

Working with a developer for your MVP can be a breeze or a brittle nightmare. It all comes down to working in synchronicity with your development teams. We are here for you, but ultimately we do what you say. We do give pretty good advice though, so never discount it! We can give some really good hints towards making your app something everyone will want to use