There are so many things to worry about when trying to start a company. How will your product be built and manufactured? What steps will you need to go through to secure funding? Should you hire a lawyer immediately or defer that cost until after you’ve developed your product? Who will you need to hire? What is your marketing strategy?
With all of these concerns foremost in your mind, the technology underlying your product can seem like a backburner issue. After all, one person can only wear so many hats. However, not having a working knowledge of your tech can lead to disastrous results like paying too much to have your product built because you’ve not been able to communicate to the developer exactly what you’re looking for, or not getting proper documentation of your code so that if there’s a disagreement with the developer and they walk you can’t just replace them. There are very few products built in our current society that don’t embrace some form of tech either in application, purchasing or discovery, so making the effort to learn to speak with your developer about the code can save you a lot of time, money and heartache.
On Wednesday of this week Goodnik, “an organization dedicated to helping social entrepreneurs access the resources they need to be successful”, held a talk at the Alley on just this topic. Presenters included Nate Heasley; Executive Director of Goodnik, Ariele Krantzow; Wix Training and Support Manager and Independent Designer, and Justin Mound; Systems Architect and Founder of Lush Comics.
Heasley began the discussion by laying out a few things that entrepreneurs should consider prior to approaching a developer:
Define your product
He talked about creating a Minimum Viable Product, or MVP, which means taking your idea and scaling it back to its most essential features. “Too much investment upfront without testing the product can really drain some resources and time and make you late to market” he said. “Really think about your goal, what do you want the user to be able to do?”
“When you are building your minimum viable product you need to build methods for sustainability.” Heasley continued. “The product achieves not only the purpose of the product, but that it is able to bring enough money or support back that you can create the second version of the software.”
He talked about creating a project plan that would, “Get down the core features that you’re going to need, your business plan and how it’s going to be used.” He stressed that it was not important to think about the visuals at this stage. They could be time consuming to create and it was more important to ensure that your product functioned as intended.
Heasley described a notecard exercise that could help you determine viability, which included these steps:
1) Lay out every feature you can think of on an individual notecard.
2) Assign a level of importance to each feature. How important is the feature to your MVP?
3) Assign a level of difficulty to that feature. How hard is it to create? How many hours of development will it need?
4) Organize the cards in order of importance and difficulty to make. Then you have to decide what you can realistically achieve.
He added, “If you don’t have a technical co-founder…you just have to guess.” He continued, “The more important part, if you don’t have a technical resource, is ranking the features in order of importance.”
After completing your MVP, Heasley suggested incorporating the features that didn’t make the cut into a more long-term roadmap. He said, “You need to know how the second version of your product is going to move beyond your MVP.” And he added, “I don’t think there is much point in planning past the second version. You have to have your roadmap but you also need to be able to adjust it on the fly.”
Krantzow then took over the talk to give specifics on designing a website. She mentioned that she assists many small business owners in building sites and that she always begins by asking them, “What is the goal of your website?” She continued, “A website, in theory, can really only have one goal to focus on.”
She agreed with Heasley that in making an MVP it was important to list the features you desired and then selectively narrow your focus. She added that wireframing, the process of visually mapping the layout or navigation of a website or product, is the next important step to take. She also agreed with Heasley that at this stage entrepreneurs should not be worried about color or imagery of what they are building and focus on just process.
An audience member asked her whether or not it was worthwhile to look at competitor sites and benchmark their features, and she said, “Go look at what your competitors are doing and do it better.”
Krantzow then mentioned a couple tools that entrepreneurs could use to create wireframes: Balsamiq and Pidoco, but added that her first drafts of an MVP are usually hand drawn. She recommended that when you finish your wireframes you should print them out, stick them to a wall and then start figuring out how they connect. Krantzow also recommended Wix as a good resource for building websites if you have no coding experience, and 99 Designs for logos and other aesthetic needs when you’ve reached that phase in the process.
Mound took over the talk and said that his goal was to help entrepreneurs understand the difference between easy and hard to build when they didn’t have coding experience. He added, “I think one thing if I could help you walk away with something is the sets of questions and the realms of questions you need to think about before you sit down with a developer.” He continued, “The number one thing that I think is hard, across the board, is design. Making compelling design for a user interface.” He mentioned that a good rule of thumb for determining the difficulty of building something is whether or not it’s been done in some form before. If your idea, or components of it, have not been built already there may be an underlying code reason that it would be difficult or costly to make. He also mentioned that programs that require lots of data being related to each other can be hard to build, but could think of a few counter examples to this rule.
He then moved on to talking about the kinds of roles you should think about hiring for if your company got off the ground. He listed a designer, developer, project manager, and systems engineer. He mentioned having a dedicated quality assurance tester as an optional role, but that QA is something that needs to be considered.
Mound suggested that when you are thinking about your product and looking for a developer you should start by researching the programming language you’d like to have it built in. He mentioned that programmers are naturally curious and often like to build in obscure languages in order to learn them, but building your product in a commonly used language will increase ease of portability between devices. He also added that it’s very important that you require your developer to document their work throughout building your product, “I’ve worked at places where that was not paid attention to and it was paid for in actual dollars down the road.”
Heasley added, by way of conclusion, “Once you’ve gone through the process of building your MVP, the last step is how far have I taken it, and who do I need to engage to take it the rest of the way?” He then turned the talk over to audience questions and it became clear just how difficult it is for a non tech-focused individual to get their tech needs met without outside help.
An audience member asked, “How do I research costs?” to which Mound responded, “There isn’t an answer to that question.” He continued to explain that costs are incredibly variable based off of what you are trying to build and who you are hiring to build it. Another audience member asked, “What about planning for data privacy issues?” and Mound responded, “The real answer to that question is that it’s complicated.” And yet another audience member asked, “How do I find a CTO?” Mound suggested they look to Jobspring as a good resource for hiring a CTO. However, when it became clear that the audience member was looking to find a CTO that would step onboard for sweat equity all three presenters agreed that this would be very difficult to find. After all, programmers tend to be well paid because the skillset is in very high demand, so the likelihood of finding someone who believes in your project enough to work on it for free is rare. Which just goes to show that if you want your product to succeed being your own CTO could be the most important hat you’ll wear.