Hey everyone, I'm a software developer and have been leading the development of an application which revolves around child behavioral tracking and pattern detection. Aside from picking a name for our new application and securing the domain we've been focused solely on prototyping the first version of the application. It involves quite a bit of data visualization challenges so we were eager to roll our sleeves up and start coding. The initial progress has been great, our technology stack is defined and our initial prototype is extremely elegant under the hood but we are currently at somewhat of a standstill.
Having worked at agencies for the majority of my career I've been somewhat spoiled in that by the time I'm writing code everything from the branding to the personas, use cases, and wire-framing has been completed. We skipped all of that due to sheer idiocy on my part or extreme excitement for what we want to achieve, not sure which, probably both :o)
My question is having jumped way ahead into the software development lifecycle, should we continue to sprint along until we get a MVP that we know we wont be happy with fairly soon or reign it in and enlist the help of both a UX and UI design resource and not worry so much about when the app can launch?
Thanks in advance for any advice!
It's a classic trap we software developers / entrepreneurs face when we think we are creating a solution and find out THE problem may not actually exist.
We are actually really *passionate* about our solutions. I see from your question that you are there. I have been there -- and continue to go there... and then... down the rabbit hole we head... until someone pulls us out.
This is me pulling you up for air (which I feel is your real request!).
I continue to keep myself from jumping into those rabbit holes. They are fun and pretty much a habit I -- and many people -- have where we love chasing the shiny objects.
It seems you have found your ONE Shiny Object.
Now... get out and TALK TO *REAL* PEOPLE and find out what the problem really is before trying to solve it.
If I am wrong about any of these assumptions -- please accept my apologies.
If I get you (or anyone reading this) to *respond* -- either negatively or positively -- then I have at least made the conversation and this answer relevant in your life!
Stop coming up with the "perfect" solutions. As passionate as you are about them.
Get out there and talk to your REAL users. Conversations. Find out their pains as they are usually not what we assume (unfortunately like a lot of what I may be doing with this answer).
*THIS* one technique will guarantee you can deliver a solid -- good enough -- true MVP and be able to pivot if (and when) you learn more!
Let me know if you'd like to have a conversation.
- mike vizdos
I am assuming you'd have gained significant insights on the probable demand for your application. If I build, they will come could be a fatal proposition to presume. I am telling this, both, after having worked with numerous entrepreneurs as an independent consultant to working with startups as an agency.
Secondly, as a yet-to-be-launched-startup your concern should be "How to monetize the App?" than thinking about something as big as branding. Branding is much more than mere having a logo.
Continuing with sprint up to MVP could be a good idea as long as you are clear with "Objective" and "Goal" that you wish to achieve post reaching MVP stage. If not, then you should simultaneously start establishing a business model around your idea. And, don't confuse business model to means to just earn revenue. It's much more than that, and in it's absence the road ahead may be ridden with more potholes.
If investment/funding is at the top of your mind, post MVP, then you should consider putting together a document highlighting following:
1. Problem your application will address
2. Value associated with your product
3. That there's a demand for such application (I have mentioned demand and not need)
4. Your strategic planning for future on utilization of fund
There could be various such critical business parameters to consider.
I hope above could be of some help to you. Please feel free to reach out to me for any specific input that you may be looking at. Receiving more Clarity from you will help me to provide more Clarity on way forward. We call it "Hand-Holding". Thank You!!
In my option, before UX and UI you need that marketing research and branding partner to do those items you mentioned. Your marketing head should have all that laid out so they can then guide your UX and UI designers on how to do their job.
IMO i've been where you are. CTOing all-in-code. But i'm not sure i found an immediately obvious way. Because it was not just my way, it has to be teams/startup's way.
Having some mostly working software that can be used as prototype and show-of-concept is good. Very good. Don't throw it away. Keep building it, Maybe slower.
In paralel, try to find what really you all want. And What is missing. Involve some possible wanna-be users. (Who are the users? Are they just one kind - or there is some completely sidetrack group that has not been forgotten? e.g. admins? statisticians?).
What aspects are weak? Is it about features, usability, product, technology, customers, marketing, maintainability, proper spec, some-future-in-2-years, shiny looks, bells-and-whistles, whatever. Then Prioritize those. Or maybe first Prioritize the aspects, from business perspective, and then find how much each one is covered or not.
We can talk more if u want. Even if only helping you identify your own problems - or just fears.
Hi Mike, there are lots of good answers here already, so I'll be succinct: One of my favorite marketers, Gary Halbert, liked to say that the only competitive advantage he wanted was a hungry crowd. You can have the worst recipes and stale ingredients in an inconvenient location with rude waitstaff and still build a profitable business if you've got a hungry crowd. So I'd recommend (re)reading The Lean Startup by Eric Ries, and giving yourself the goal of doing 100 customer interviews in 30 days. Focus on two simple questions: 1) "If I created this [your software], would you pay for it?" and 2) "What would it be worth to you?" Over the course of those 100 interviews, you may either validate your hungry crowd or it may disappear. Regardless, don't keep building unless you're 100% certain that people will PAY for your specific solution.