Without a technical Co-founder, it's a very hard job to manage backend progress.

I am (very) technical. Yet, deadlines are still delayed regardless. That is the nature of a business with traction. Customers are pulling the product out of you. You are always a few steps behind where you know you should be.

There are a few things I advise friends and founders which are not technical:

1/ Focus on what you are good at. Setting up a Sales pipeline, building a customer support with a 1h SLA, these are definitely things you can do without waiting for a tech co-founder. This will also have the advantage of attracting the tech talent you are looking for. Unless you are doing research in quantum mechanics, building a mobile or web app can be done. It is not a risk to your business. Any tech co-founder knows that. They will be looking for your skills to build traction before committing. Focus there.

2/ If you pay someone $25/h and they take 4h to complete a task, yet it is still half-done and buggy, then you are better of hiring a more skilled contractor at $100/h that completes the task correctly in 1h.

3/ Most delays and frustrations are due to mismatch expectations and communication. You are the product manager. It means:
a) miscommunication is your fault.
b) poor quality is your responsibility.
To communicate better, learn the key points of writing step-by-step user stories, writing clear GitHub issue description, and the basics of Continuous Deployment (CI/CD).
To improve quality, be ruthless (borderline maniac) in forcing a cadence (ex: "new code must be live every Monday"), in testing ("all issues reviewed/prioritized every Tuesday"), in asking developers to redo, and redo, and redo again, the same feature until it is of acceptable quality.

Heya, I'm a product owner at a medium sized tech company in Australia.

My suggestion would be to change your perspective a bit. Instead of thinking in deadlines, think in increments of value. Rather than structuring work as "must be done by X", you can structure it as "this is the next most valuable thing we need, ship it when ready so customers can start using it".

This approach is basically some of the core tenets of 'agile'. Focusing on delivering the highest priority thing of value rather then WHEN you deliver just any-old-thing.

There's a lot of tooling out there, and depending on your size, etc, there's plenty of recommendations I could make.

My cookie cutter one would be consider implementing a very simple (to start) kanban board. You, as the product manager, are responsible for fleshing out the items in the ToDo and making sure they most accurately represent the business intent, and the outcome you want. As the product manager, you are also free to move things up and down in priority in that list.

That way, when your tech team delivers an item, they are able to pick up the next highest priority item, knowing confidently that this is what the business absolutely needs next, and there's plenty of useful context and parameters which define what success looks like.

--
This sort of thing is near and dear to me. Let me know if you have any follow up questions or better yet, if you think I've missed the mark, let me know that too.

I feel as though all companies have this issue where non-technical people don't understand why the technical stuff takes so long. There is no answer or solution to this problem other than learning about the technical stuff to gain an understanding as to why this is the case.

Software forecasting and estimating is inherently difficult to do. A good rule of thumb is to take any estimate given, and double it (if the developers are savvy, this will mean that the original estimate may be x4 times what they originally though it would take) - but this is safer. Software development is more about managing expectations than writing code fast. Fast code is bad code.

I guess the crux of the problem is: Some stuff that seems significant can be done very quick. Other times, the stuff that seems insignificant can take a very long time.

I think deadlines are inevitable, regardless of how the project is structured :) Sure a tech co-founder could help, but owning the whole thing yourself isn't a bad thing either. (Assuming you are a solo founder).

Being technical helps you to understand the real price of a task, and not being taken advantage of. Anyway, with a little bit of extra work, going further and getting quotes from different developers you'll figure out the correct price yourself.

Deadlines being delayed is a completely different thing; it's a management problem:)

When outsourcing developers I'm always pro spending the necessary time to search and properly interview each dev. You might have to spend 1h with each of them and feel like wasting good hours of your time when they are failing you over and over. But only in this way you'll find that person down to earth who will understand exactly what you need and have the right skills for it.

From there, you can negotiate the price, set clear deadlines with payment milestones, and stick to them.

PS. You don't need a co-founder. It won't be like this all the time. Soon enough you'll get your first technical employee and he/she will take over these tasks.

I think it's less about having someone technical and more about experience in managing expectations. Everyone assumes that things will work perfectly on their first go around because they haven't seen just how skrewed up things can get. The best you can do is realize that you were wrong in your initial estimates and find out why.

Then the hard part, learn from your experience. A lot of people think that means never make the same mistake twice, smart people know that means realizing that you, as a human, are prone to mistakes. This is the basis of risk management theory, something I myself am not sharp about, but it's good to keep in mind going forward.

Best of luck brother, just remember, you can always improve yourself.

You can get a long way using a no-code tool if you're product is early/MVP stage. If you haven't checked out Bubble.is I highly recommend it. Feel free to reach out if you've got questions -- a lot of very powerful applications have been built with Bubble powering the front and backend.

Proving your concept with a prototype or rough working version is a great way to get feedback from customers, demonstrate product/market fit and attract technical co-founders.

ericslab.com