What Can You Do for Your Dev Team as a Non-technical Founder?
As a non-technical CEO it’s an obvious challenge to build a personal relationship with the development process. It would be easy (and is apparently common) to declare yourself clueless, and conveniently drift into separate silos — you build the product, I’ll take care of business stuff. Maybe we’ll meet at the weekly standup and exchange ideas.
Every single agile development advice screams against this, and the usual cure is to hire more people. To place product owners and product managers between business and development, analyzing customers and translating the insights into practical input for the coders.
But what if your whole startup is still just a few people? What if your list of expense priorities is so long that hiring a product manager (or even contracting a UX designer) is not even on the first couple of pages of the list?
We’re a tiny team working on Zelos, building SaaS tools for communities and gig work. And the more skills we’re able to pack into the core team, the better product we’re able to provide to our clients.
Sooo.. everybody needs to upgrade all the time. Especially the non-technial CEO (that’s me).
Product management is just management
Last autumn I completed a 20-week online course from the Darden School of Business to learn about agile product management. This was before I got into the blogging habit, so those learning pains are directly undocumented.
However, those 100 hours gave me lots of tools to become more useful to our development team. And the main takeaway to everything is that product management is.. just management. Creating order in ideas and doing the heavy lifting on whiteboards and spreadsheets is the same everywhere. It doesn’t matter if you’re making sense of the marketing strategy or product development epics.
I’ll summarize some details of what has proved actually useful so far:
I learned to write user stories
This is a format of fiction that describes your customer activities without any technical terms, but is still easy to understand by someone who thinks in terms of back-end data structures.
Having the ability to write these down for reference and establish them as a common source of knowledge in our discussions has radically upgraded our quality of talks about our product.
I don’t see the development team in an early stage startup putting enough effort on this by themselves — they’re coding night and day! Also, as I’m the founder more hands on with demo calls and sales, I wrote much more thorough user stories than our CTO did on his own.
I learned to recognize and document triggers and rewards for user behavior.
As consumers, we are so used to standard processes in the apps we use. When we send an e-mail, we think it’s a given standard that our inbox displays the “e-mail sent” message. But these displays and messages are placed there by the people who built the software. And they’ve put in some thought about this — what happens at key moments when you interact with the thing.
Gaining the ability to analyze and document our user journeys for these missing pieces and generally chew through the processes was a huge upgrade for me.
Technical founders are not always good administrative founders. Genius coders don’t always love documenting their processes. They’re here to build things. And you can really really help them if you’re good at admin work.
I learned to document roadmaps and set development priorities
Before you have strategy, you make decisions based on gut feeling. Do we want to build the email feature first, or should we prioritize getting edit buttons into the mobile app?
These are important decisions that may have a huge impact on your business, but without a product strategy, you’re a weathervane in an autumn breeze.
It’s easy to give in to customer demand — there’s always that one loud client who’s not even paying you much! It’s also tempting to avoid the long conversation with your CTO altogether and have them pick their battles based on what seems easiest / most interesting at the moment.
The problem is not that you should disagree with your clients or CTO — the problem is that a good product strategy takes a lot of admin work. And neither your clients or your late-night-coding-CTO are up for putting in the long hours of admin work.
Copy-pasting stuff around strategy documents is a CEO job.
Bad usability is usually a non-technical problem
Startup hackathons often present UX as a design challenge. Freelancer portals promote portfolios with good-looking app mock-ups. Obviously the look and feel of software plays a crucial role in usability, but it’s just the top layer.
Not many usability problems are caused by technical errors (unless your app is so bad that it just doesn’t work). Most usability problems are caused by nonsense issues — users just cannot figure out what to do, get frustrated and leave your product.
So — however good-looking, your app will not be a success if it doesn’t make any sense. And sense-making is a non-technical problem.
A month ago I signed up for a mentorship program with the Futurist UX agency — I’m getting bi-weekly 1:1 mentor sessions to help me make sense out of our value proposition. And for the most part of it, it’s been about sticking post-it notes to a wall — a lot of usability design is absolutely non-technical.
Creating a customer journey in product
We had never before laid out a full customer journey in product. We had a customer journey map that laid out the stages of awareness, consideration, decision, use, and loyalty. It’s a standard business canvas that is supposed to have some product-related keywords under “touchpoints”. For example, we expected the customer to (somehow) interact with our website, app, chatbot and email during the stage of decision-making.
But none of that answers the more specific questions.
Creating a customer journey in product took us two long days of active workshopping. It’s a tough format for the CTO as it forces a linear narrative that’s a bit unreal. No actual user will follow the ideal narrative and you need to create a make-believe scenario while looking through rose-coloured glasses. Not easy for someone who’s dealing with real and nonlinear problems on a daily basis.
But in two days we managed to draw up a linear narrative. We wrote down every single thing that ideally happens to our customers when they start using our app. Then we went in and edited everything. We remembered important things. We made decisions on the order of things and changed it around some more.
Eventually we had a document with five lanes (website, app, chatbot, email, community) and three phases (decision, onboarding, use). Each post-it is an event or activity that the customer is taking in the Zelos ecosystem.
We created this journey about a month ago, and it has already been a priceless point of reference for multiple issues. It gives us answers to so many questions that we’d usually just answer with a gut feeling or a heated discussion.
It has also been a clear starting point for research and design for our new mobile app design. And I’m proud to say I’m actively working on that design document myself.
Although anything I create will certainly not be good enough to put into production, our dev has already been grateful for my inputs as I’m doing the hard work of arranging ideas. The tedious research, idea synthesis and figuring out business logic — they are all non-technical, and require no coding skills.
I promise to write another blog post on this non-technical mobile app design process soon — subscribe to the blog if you want an update on this 😉
