From Zero to App Store won't focus on running a business on Apple's platforms, but it touches on a few ideas and concepts that relate to business. This episode focuses on defining the first version of the product. In the startup community, this is often referred to as defining the minimum viable product or MVP for short.
Cocoacasts isn't a startup, but it's essential to set aside some time to define a roadmap for the product you're building before you write your first line of code. The biggest mistake you can make is opening Xcode and writing your first line of code before you know what the first version of the product should look like.
This phase is straightforward for Cocoacasts. The idea to create a native, mobile client for Cocoacasts has been in the back of my mind for quite some time. I have plenty of ideas for the application. The challenge is selecting only the ideas that are essential for the first version of the application. Consider the following example. I plan to support tvOS, but it would be crazy to include support for tvOS from day one. Even if you're working in a team, you need to stay focused and eliminate anything that isn't absolutely essential. Keep bells and whistles for later.
Defining the First Version
I like the idea of defining a minimum viable product because it best describes what the first version of a product should look and feel like. My goal is always to get something in the hands of people as soon as possible. That strategy is only viable if you stick to a few rules or guidelines.
It comes down to two simple questions. What is the goal or purpose of the product? That question is easy to answer for Cocoacasts. The goal or purpose of the application is to allow people to read and watch Cocoacasts on their mobile devices. That's the core idea and that won't change. It should be possible to define the goal or purpose of the product in one sentence. If you need several sentences to explain the core idea of your product, then you have a problem. It most likely means your product lacks focus.
The first question should be easy to answer. The second question may be less trivial to answer. What is absolutely essential to the product? What is necessary to make the application useful and functional. Developers and entrepreneurs usually have a long list of features they want to include in the product. Answering this question means removing the features that are not essential. Only the features that are critical make it into the first version.
What does this mean for Cocoacasts? A user should be able to read and watch tutorials published on the Cocoacasts website. It should offer a native experience on their mobile devices. That's the short answer.
Focus. Focus. Focus.
The only way I can stay productive and get meaningful work done is by focusing. From the moment I lose focus, my productivity drops. Focus is critical in software development. That is why the first version of the application focuses on iOS. Adding support for tvOS comes later. To support tvOS, I need to address a different set of problems and that split focus isn't going to help me release the first version.
I could take it one step further by focusing exclusively on iPhone. To offer a premium user experience on iPad, you need to invest time and effort. This can sometimes be a difficult decision to make and it is for Cocoacasts. Because video is such a core component of Cocoacasts, I feel it's essential that iPad is supported from day one.
Trying to cram too many features into a release is asking for problems and a common cause of missed deadlines or, even worse, applications that never make it into the App Store. There's a good reason why I write about productivity from time to time.
What to Expect
What is the plan for the first version of Cocoacasts. The most basic implementation would be to enable users to access Cocoacasts tutorials. That's obvious. But there's a catch. The application is most useful to Cocoacasts Plus subscribers, which means that it should also include the ability to sign in and access Cocoacasts Plus tutorials. This small addition drastically changes the scope of the first version, but I consider it an essential aspect of the application and it should be included in the first version.
Let's summarize the scope for the first version by defining a few user stories. - Every user should be able to see a list of Cocoacasts tutorials. - Every user should be able to access a Cocoacasts tutorial. - A user with an active Cocoacasts Plus subscription should be able to sign in. - A user with an active Cocoacasts Plus subscription should be able to sign out. - A user with an active Cocoacasts Plus subscription should be able to see a list of Cocoacasts Plus tutorials. - A user with an active Cocoacasts Plus subscription should be able to access a Cocoacasts Plus tutorial.
This is the most basic version I can think of that offers enough value to both anonymous users and users with an active Cocoacasts Plus subscription.
Setting Deadlines
I won't be working on Cocoacasts full time and that makes setting deadlines challenging. Even if you decide to set a deadline, I always recommend to keep deadlines private. Many people make the mistake of setting public deadlines. I've made that mistake several times in the past. It has its advantages, such as accountability and a healthy amount of stress, but it can also lead to frustration and an unhealthy amount of stress.
Setting no deadline isn't a good idea either. If you're serious about a project, however small, you should keep yourself accountable by setting a deadline for yourself. It keeps you motivated and something to look forward to. Shipping software is incredibly exciting and that should be a major focus, especially if you're building a product.
What's Next?
The next episodes focus on laying the foundation for the project. That includes setting up the project, putting it under source control, and creating a release workflow. The latter may sound premature, but having an automated system in place early on can save you time and it's a joy for everyone involved.
