a) learn to code, and try making it all yourself. May well take like 1-3 years and more
b) find someone who can *make* software (coding is maybe half of it, maybe less), and wants to participate, and u trust hir, and u can cooperate well.. so - team up and share the project
c) pay someone to do it, person or company. Again needs trust

choose.. Most fun is probably b), but YMMV
ciao
svilen

Try Build a prototype. Mock-up if needs be. Present/"sell" it as idea to a limited circle (maybe starting with just you as user). Throw away.. most of it (the prototype, not the knowledge gathered). Rinse. Repeat. Several times. Every time decrease the freedoms, harden the model and narrow the focus, and expand the circle of surrogate-"users", slowly finding the eventual target (people or domain or point-of-pain). Eventualy involve marketing/management types as another kind of users (not of the thing itself, but of the process of it's creation). Note i did not mention "software". u can apply this to a Rough idea - it is also kind of virtual "software", but running inside someone's head.
Ah, and have fun.

Models... no. Been there.. done that. But There are bunch of questions one has to ask hirself, time and again, and in most cases, one does not dare ask them. Esp. if u wear 5-6 hats (in most cases with contradicting goals). For everyday life u may get those asked in a pub by next stranger, but not for work-related topics needing huge amount of technological background... There comes the expert/mentor who would not mind sending your hopes/illusions to hell and back, or suggesting something unthinkable. Things like 360' exploration (in begining), building correct product vs building product correctly (all the time), release unfinished but early or all perfect but late (at end), etc. See this http://www.svilendobrev.com/rabota/metodologia.html or this http://alistair.cockburn.us/Cooperative+game+manifesto+for+software+development ; and although these mostly talk about human-side, it's same stuff on technical side, just with different names. Have fun.

First rule of leadership is: Leader is guilty for everything.
My rule for it is: it's all about Trust. Mutual.
Are u a real Leader? Then stick with them. Work together. Do their shifts/stuff if they cannot come in the afternoon. Let them take your shifts/stuff when u cannot do it. Share living and working, together. And all this under pressure. Long-enough to start knowing who thinks of what and how, when s/he says this or that. Or when s/he writes such and such code. The saying goes like - Eat a 10kilo of salt together... By that time u'll have a feeling about everyone, who is able of what and unable of what, how fast s/he thinks/learns/find/a-way-out, how persistent s/he is in chazing a defect/completeness/perfection, and all those. As bonus, u may become friends. For life. Anyway, here's my take on work/teaming/trust etc http://www.svilendobrev.com/rabota/doverie.html and around

software IS 99% about people. One thing, u have to define "fast enough". Amazing things are not done in one friday afternoon. Polishing, licking if u want, takes time. A lot. And, analytics has nothing to do with it. For fast projects, u may need different kind of people, who can cut corners and sacrifice some qualities and thoroughness for speed. But u still need pressure to cook something. A project always soaks all the time u give it. Hence the kind of people who can push. Few can both push/lead and dev/design. Find some. On another note, u may have something completely broken in the management, company values and their perception, and all that. Culture is not just a single definition/motto/slogan. It takes gumption.

culture change is the most difficult of all changes. And u may need to decide on which culture dimension u want/can push a change first. Needs a study of status-quo. i've done few of these.. maybe can help u there. But to the point.

There will be resistance.
http://dhemery.com/articles/resistance_as_a_resource/

and there will be battle.
http://www.scrumalliance.org/resource_download/679

How do u feel about Trust there? Trust is the hardest to gain and the easist to go. Measure it somehow.. and start increasing mutual trust. Knowing each other helps. A lot.

the Lack of communication is the point of change. All else is not interesting. Analytics isn't going to change anything - u apply that to something that already works well, to measure and improve it. Yours doesnt work.
Accountability maybe, but if implemented without proper transparency and Trust, it will just turn people away (responsible but powerless).

so... as suggested. Start small. Have a look at organisational patterns book http://www.amazon.com/exec/obidos/tg/detail/-/0131467409/, print the most obviously missing/matching of them and "accidentaly" forget them by the printer or by some coworker (who u think might take it). Don't force it - try find allies in higher places.
Look at me site for more recomendations http://www.svilendobrev.com/rabota/ which although seemingly purely software, are more philosophical i.e. generic in nature.

Anyway, essentialy - do best u can, looking furthest u can. Don't micromanage in any way (analytics is such). And yes, Have fun.

i have been there (Assuming you're the technical one). Many times. i know the pains. Esp. the pain of switching contexts and fighting with oneself, as the different hats have orthogonal or sometimes contradictory goals/needs/interests and u have to keep all of them inside your head.. and not blow up. And not mess the code. And not mess the UsrXperience. And not mess the system as whole. And you probably would not even think of the Business hat.
Or if u do, it would be wrong, probably - too many other biases.

My solution so far has been to find a small variant of the thing where i am the end-user. And build it for myself. No business at all. Maybe show it to someone else who can be user. Or co-developer. etc. Thus keep it alive, in a form, until u find The business-person. Or become the one.

So far my success rate in such finding.. is below 20% (i've rejected becoming the one myself). 1 out of 5 projects.. or less. But don't despair. Maybe u live in place - or application domain - with better business-persons climate. Keep looking.

Maybe i can give u more insights (or traps to avoid). Or just listen to you, attentatively. It's sometimes enough to clear one's mind about things.

have fun

i've been in such situation..
So just tell hir so. If you're in generous mood, give hir a week (or 2?) to switch. But it'll probably be a waste.
btw, consult the team about it. If they also say s/he's more trouble than helping, then bye-bye. You cannot afford "negative" performance - someone reducing others performance in this or that way. The team might be better without hir - more work to do but at least no fake stuff..

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.
Have fun.

Change for sake of change or new tech for its own sake isn't anything good.
But Seeing different aspects/qualities of same thing and not communicating it across is also no good.

Maybe you are above him/her. Make sure you both have noses in same direction, looking at same thing+aspect AND talking about it. Try to live in each other shoes. Commucate a lot. About the why's. Anyway, at the end, It's all your fault, and there is one tough managers choice - change People or Change people. Including you.

Or may be you're under him/her. Have a look at Organisational patterns book (James Coplien, Neil Harrison, http://www.amazon.com/exec/obidos/tg/detail/-/0131467409/). Find some really matching one and leave it "accidentally" by the printer. Yes, organisational, not technical. Technical may follow, later, as they are response/solution to something. Find/point out that something that needs being solved.

In any case check the "Resistance as a resource" (D.Emery, http://dhemery.com/articles/resistance_as_a_resource/)

and... be careful. Change can be .. demanding.