How do you approach product development when you start with nothing, like at Tixers, compared to starting with something, like at CrossChx?

My first product was a Craigslist-type platform for Ohio State students to buy and sell anything from football tickets to textbooks. When I first thought of the idea, I didn’t have the ability to build the platform nor did I have the resources to pay for development. I didn’t have much, but I did have friends who had some level of affinity for me and were willing to build the product for free.

When I helped start Tixers, we were super scrappy, even after seed funding. We sat down and calculated our cost of living and paid ourselves accordingly. We tried to keep as low of a burn rate as possible, we didn’t even buy company T-shirts.

One of our developers was working full time at another local company. I convinced him that working for me would be fun and got him to moonlight for us on a shoestring budget. It goes to show that you should never underestimate the value of resources that aren’t cash. There are some very quality people out there who are willing to trade in a well-paying gig for something that gives them more value, time, or fun.

We’re obviously here to talk about being “Lean,” and being Lean means that you build, measure, and learn as cost-effectively as possible. When it comes to the “learning” piece, there is no substitute for customer interviews. Whether it’s before, during, or after the build, you need a lot of unbiased feedback on how the product should work. The only resources you need are time and the ability to find customers. The knowledge you learn from interviews is invaluable and they’re often overlooked by product teams. There’s so much you can learn without spending any money or writing any code.

For a patient intake product I built at CrossChx, I interviewed everyone involved in that process from physicians, to office managers, to receptionists. I didn’t start with “What’s your patient intake process like?” I started with “Walk me through your current workflow.” Then I moved into “What is your least favorite part about that?” I drilled down from there but kept the questions very open-ended.

If you have an idea you’re trying to validate, don’t ask leading questions to try to get to an answer. Understand your customer, their workflow, and what their problems are. How painful are those problems? Are they currently looking for solutions? How are they looking? Where are they looking? Asking these questions will uncover commonalities and will help validate or invalidate your hypotheses.

How do you make sure that the development teams are aligned with the business?

No matter the size of your company, you’re probably strapped for resources. To maximize resources, you want to be lean and stretch those resources. To do so, the first step you need to take before developing something is to ask “Should I be building this?” This goes back to what I said about customer interviews. You never want to build something that nobody wants.

At CrossChx, when I hypothesize a solution to a problem, I validate it with customers. After validation, I’ll typically wireframe a solution and hand it off to my designer who builds out the UX. Then, my designer and I get together with a front-end engineer and a back-end engineer to talk about what it looks like for the user. The engineers usually poke holes all over our assumptions so we often take it back and retool what the experience looks like. We turn those into tickets in our project management software, Jira, and once they’re developed, we put them into testing and validate those features. I try to maximize my engineers’ building time by taking on a lot of the QA myself.

How do you prioritize your backlog? How do you measure the success of what you prioritized?

At the end of the day, whatever you prioritize has to have a strong and measurable impact on the user. For me, it’s being aligned with my user and what they want. I feel I’ve done a good job at the customer interviews so I feel that gives me a great intuition of what the customer really wants and which features will be most important to them and their problems.

We put analytics on everything we build. Every product requirements document has a hypothesis of how it will help the user. I specify a problem statement, an assumed solution, and things I see that are in-scope and out of scope for this project. After that feature is in production for a while, we can gather data and determine whether or not it aligned with the hypothesis.

Thank you again, Jay, for coming and sharing your product wisdom with the Taivara network.

More Resources: