Posted: April 26th, 2011 | Author: irv | Filed under: Companies, Programming | Tags: business, code, features, startup | No Comments »
Over the weekend I have been thinking about which features should be implemented and in what order. I realized that it didn’t make sense to try to prioritize each possible feature, as there are thousands of them, because that would take too long, and not necessarily result in a reasonable prioritization. I started to think up a framework for deciding which feature would be implemented when.
One of the first things to think about was the framework of the startup, or which development strategy the organization is using. In my case, we are using a lean-agile approach. This approach suggests that feature decisions should be based upon whether or not the implementation of a feature will affect positively any of the key metrics of the startup. An example would be, if you have a freemium product, conversions to paid from free.
What I would add to that philosophy, is that it isn’t enough that it move one of the metrics, but that it move the right metric for your startup at it’s current growth stage. If you are raising money, then gaining some sort of traction is likely more important than long term customer retention. If you already have product market fit, and you earn revenue through use of the product, then it makes sense to focus on making your software more pleasant to use.
To clarify this for myself, since I tend to obsess about usability a bit, I thought back to when I switched from PC to the Mac. I was telling myself that it was largely because I liked the usability of the product better, while this was true, it wasn’t why. I had just received a video camera at the same time and was playing around with various low-end PC video editing software, it basically sucked. Then I found out that the Mac came with iMovie. iMovie was far from perfect, but it was really good and gave me a capability that I didn’t have before. I could now edit long home movies easily, and burn them to DVD.
I realized that Apple got me to convert on a first order feature, and retained me on a second order feature. That is they gave me a capability that I didn’t have before, thereby converting me from a non-Apple user to an Apple user, and I created mainline revenue for them.
Apple has always been about this, when thinking about the iPhone 1, what did it do for me. Well, it didn’t have a ton of features, some of the ones that it did have were missing obvious things that it needed, like copy and paste, and it took a long time to get them, at first I didn’t understand why, but later it made sense. Apple was optimizing for that initial conversion, the product gave me the capability to use the internet and share photos in a minimal, yet useful way. That was what made me convert. If Microsoft had done that then I would have bought a Microsoft phone that day.
So what I decided was that I needed to figure out what the startup needed, right now we are fund raising and trying to acquire customers, so to me that means that we need to have features that get people to buy. Those would be first order, first priority features. Those things, that would make a material difference for the startup, and answer the question for the customer “what fundamental thing can I do with your product, that I can’t already do.” That is the question you must answer to get people to convert.
Second order features, the features that make your product nicer to use, are all features that are incredibly important. However, depending on your business model, you may be wasting time based on your organization’s goals working on second order features when you haven’t figured out the first order ones. Frequently when you see startups die, this is the reason. They are working on things like performance, or some trick usability thing that is really awesome and hard, so it is sucking up time, meanwhile you aren’t adding users because you have failed to answer the critical question. Maybe you know what your product will do in the end that is transformative, but your prospective customers don’t know. You must work on transformative, game changing, disruptive features first.
Posted: April 3rd, 2011 | Author: irv | Filed under: Programming | Tags: building, business, farming, mining, startups | 1 Comment »
Wil Shipley wrote a great article about mining vs farming when building software and a software company. I have been thinking about it and I wanted to offer my perspective on it. Let’s start with this quote:
The problem with mining in the software business is that it doesn’t work. It creates broken, useless companies.
Founders and angel investors usually don’t particularly care if the companies they created live or die after they sell out, because they’ve gotten their money and moved on. There’s no stigma to having a company you founded fail after you leave it. In fact, again, it’s a badge of honor: “Bob Smith founded Flopper.com, sold it for $46MM, then got out before it tanked! Genius!”
Well, while I agree that there is a clear incentive to get to market and sell, people do like money, and it does create some broken companies, I don’t agree that this is a bad thing. The entire point of a startup is to search for a viable business model. Once you find it, occasionally the founders can continue on, but frequently the founders find somebody who can clean up the mess and make a killing off of the awesome opportunity they have discovered. However, and this is where the broken companies come in, the founders never find a business model. They love the idea so much they sacrifice too much in quality, spirit, and finance to keep something going that can never work.
So in a healthy economy in general, you are going to have some companies that just have broken business models and terrible code and will fail. Then you have companies that want to farm, so they take huge amounts of funding, or time, to build up fantastic and impeccable structures of code, but they haven’t released anything so they don’t really know if customers will want it. They build for years and launch only to find that customers yawn, or worse are antagonistic to the product after the hype cycle. Then you have a company with great code and developers can never work. The founders often take more money, rinse… dry… repeat…
Finally, you have startups that, crank out an MVP the code behind it is terrible, the execution is only So / So, but they get it to market and customers love it. Now they have found a market. Its time for the professionals to come in, clean up the code, allow the founders to focus on product, get professional managers, etc… and go… go… go… Unfortunately this is rare, typically terrible architectural decisions will make it challenging for the team to ever get ahead of the fixes to start iterating on the features that customers are telling them that they want. However, it is frequently necessary to keep analysis-paralysis at bay and get it done.
You can mine, as long as you acknowledge that you are mining. This is where code and business concept documentation come into play. It is fine to write terrible code to get to market quickly, as long as you have documented any shortcuts, and in general everything assiduously. If someone has spent months to come up with a fantastic piece of code but doesn’t document it, it doesn’t really help anyone else learn. It also makes it difficult, if it ultimately isn’t so clever, for someone else to fix it because they don’t really understand the entire rationale behind what they were thinking when they wrote the code.
The “ramp” of someone getting up to speed with code is largely due to negligent documentation. You can find this in “farming” companies or “mining” companies. If someone can read a brief synopses of what a piece of code is supposed to do, why it was supposed to do it, and how, they can typically come to an understanding of what was in the author’s head. Otherwise, you have a long slog ahead of you reading through the code and either writing out, or mapping in your head all of the possible branches, dead or otherwise.
The secret of success turns out to be so incredibly simple: Work your ass off. Really care about what you’re creating, not the fame or fortune you’ll get. You’ll succeed.
I definitely agree with this part, just focus on your customers. Make sure they are surprised and delighted when they are using your product. No one should be in this just for profit. Mostly because it isn’t worth it. Coders spend so much time behind their keyboards, they damn well better love what they are doing or building, if they don’t they will quit, or burn out. This is the real truth behind this developer shortage. There isn’t a shortage of good developers, there is a shortage of great concepts for them to work on. If you build it, believe in it, and its awesome, they will come.
Posted: July 6th, 2010 | Author: irv | Filed under: Companies, Lifestyle, Programming, Uncategorized | Tags: business, corporations, engineering, Lifestyle, millenials, Programming | No Comments »
Disclaimer, I am not a millennial, I am in that strange area between generation X and generation Y, being closer to the Y. What does that have to do with the topic, you ask? It puts me in a unique place to watch the struggle of ideas unfolding between the engineers coming into companies, and the engineers / businesspeople running corporations. This is not to say that all current executives are outdated, but in many companies, they have failed to update their model of the world to match increasing numbers of their customers, and the incoming flock of engineers.
The fundamental issue is that people who have had success in the past have a hard time considering that what gave them the success in the first place is not likely to continue producing success. As an example, existing business processes for tracking hours is typically to have each individual estimate ( after the fact ) how many hours they have worked on a specific project on a given day. The current method, as best as I can tell, is for engineers to estimate via points how much time it takes to perform a given programming task and do a post-mortem if the task takes more points. But this daily reporting is eliminated, which is a better, more efficient process. It is also one that revolves around trusting the engineer.
Another example is that it is not uncommon for developers working on a project to push out information about that project to the public via Twitter. Even down to the level of code commits. For the users of that product, they can choose to follow the official company feed or they can decide to follow their favorite engineers. The concept of privacy has been diminished to a large degree in modern companies. The benefit of this is that users become partners, not only in the debugging and troubleshooting process, but also in the development and planning phases. You can find, for just about any startup, engineers posting what features they are thinking about and feedback from engaged consumers, either providing amplifications, their own feature suggestions, or strong negations about where the company should be spending its precious resources. In such an environment, extreme secrecy is a huge liability. Likewise, within corporations, keeping the status of the company, and what the customers are saying about the products from the engineers is disastrous to engineers’ morale, as well as harmful to the level of understanding of the executives as to what is happening within the company. In more modern companies, the developers are treated like the partners of the product managers and the executives.
I think most of the fallacy in this regard comes from the manufacturing metaphors that have dominated the majority of the corporate worlds’ view of software development. When I look at the waterfall method, and some of the organizational structures around engineering departments, what I believe is being attempted is to reduce development to an assembly line with shift managers and the like. This can’t really work for software engineering for many obvious reasons, but probably the most obvious is that programmers, even self taught ones have more in common with lawyers than they do with assembly line workers. Assembly line workers can highly optimize their tasks due to the extremely specific level of requirements, as well as the consistency in their tasks. Developers, and the product people working with the developers, almost never have requirements detailed enough to complete the given task. Similarly, developers have a wide latitude to perform tasks in different ways as tools, managerial practices and or technology change, which is nearly daily at this point. While most manufacturing systems change once every 20 years or so, a particular manufacturing worker can master their skills and have that be applicable for their entire career.
Attorneys are typically highly specialized, and operate with a widely varying set of rules, like software engineers, they need to parse and execute on sets of specifications ( laws ) to the benefit of the person contracting or paying them. Their interpretation of a given law may not always be standard, but if it achieves the intended goal, then they are considered successful. This interpretation in law as in software engineering is more of an art than a science. This variability in going about the job from day to day creates odd management challenges that are being exacerbated for software engineering management as the millennials come into the workforce. To a large degree, having fewer, more productive, empowered engineers is obviating the need for traditional engineering management. Of course someone needs to be accountable, but if you have small groups of developers, the group can be accountable for a specific feature. Small groups of engineers make it easier for them to triage why something went wrong and prevent it from happening again. Failure is part of the software development process, but it doesn’t have to be a destructive part.
Millennials, and their immediate predecessors appear to be very comfortable with dealing with this sort of environment, they do not seem to need clear guidelines or even a clear goal. Many software projects that utilized the “agile” philosophy, which even itself is becoming dated, typically manage the process with smaller tasks that everyone in a company seem to be involved in creating. The new crop of engineers seem to be more comfortable with the self-taught, with it being more about what you can show than what you have done. Resume’s appear to be losing their value relative to a solid portfolio of open source work and products. My advice to people in high-school and college about to enter the work force is to work on a portfolio of applications first, or contribute to some open source projects, even more than attempting to get an internship at some big company. If they can make some money off their portfolio, all the better. The teams appear to be more distributed, with wide acceptance that each individual is working on their own business ideas not related directly to the company’s goals, or product portfolio.
All of these things fly in the face of the traditional command an control structure, however I believe that it will speed the pace of innovation, and improve the overall level of developers. Smart companies will harness this multitasking and openness and provide avenues for their developers to contribute new products under a “labs” or a “demo” banner, even if they have nothing to do with the products that the company makes. These companies will not mind as one of their “labs” projects earns more than their flagship product, and will provide the creator of that product a team and budget to see how far they can go. That will rapidly become the only way to retain talent as the cost of starting a business online continues to drop. Executives at these companies will treat their developers as peers in strategy as well as in the software development lifecycle. It will become clear that this method of structuring a business is correct when not the one, but the many startups offering services begin to completely demolish the incumbents. It is going to be an interesting ride… are you ready?
Posted: February 9th, 2009 | Author: irv | Filed under: Apple, Companies, iPhone | Tags: Apple, business, iPhone, nano | No Comments »
I think for Apple to build an iPhone nano would be an indicator that the end of Apple is near. To be clear, I do not think that Apple will build any such beast. However, let’s postulate a scenario where Apple builds such a thing.
Firstly, let’s look at a picture of where the iPhone currently is. Apple has a device that for all intents and purposes is $200 that is selling at a brisk clip. Not to mention that people are snapping up applications at an even more intense rate. All of this is making Apple rich. There are several questions that occur to me when thinking about a conceptual iPhone Nano.
- What does Apple have to gain from such a device
- How do they account for it technically
- What type of person would buy such a device, and how do they fit into Apple’s core demographic
- What sort of hardware would be in the iPhone nano
Let’s talk about number one. What does Apple have to gain? If Apple were to build this mythical device, and it were to be smaller, etc… How could they build it cost effectively, their parts chain is tied up in 320 x 480, 120 dpi screens, ARM-1178J CPUs, etc… They would have to negotiate and buy a bunch of different parts. Tooling up for a different device line would be expensive right now. Then, assuming they spent the money on that. They would need a sufficiently different software stack for this device. That would cost money as well, then lets say that they pulled off the miraculous and got the iPhone nano’s manufacturer’s cost down to $299 ( which would be amazing ). Would AT&T really do another hefty subsidy, to get the cost of the device down to$99 or free when their bottom line is already hurting from the steep discounts on the iPhone 3G? The answer is no, it doesn’t make sense.
On the technical side, how do they account for an iPhone nano? Assuming that the device would have a different form factor, most applications would have to be rewritten, not necessarily for technical reasons if they used interface builder when creating their UIs, but for usability reasons. If the screen had a much greater density, it would be harder for the user to see text, etc… So developers would have to make their fonts larger and change their navigation and text entry systems if it used a click wheel. That really makes the AppStore out. This makes no sense.
Who would buy an iPhone nano that wouldn’t buy an iPhone? This is interesting. The iPhone 3G is doing well even with the income challenged segment, so who would buy the iPhone nano? Maybe kids, perhaps teenagers, but without the AppStore, what is the draw over a normal iPod? Or the iPod touch for that matter. Maybe the extremely impoverished would consider it as a stretch, but if you are that challenged for cash how would you afford any monthly plan with data attached? Does AT&T want credit challenged, cash strapped customers? Does Apple want to serve the bottom of the market, even though they don’t in any other case? No, they don’t.
Finally, what sort of hardware would be in a thing like this? Well, they could use the same chips and just underclock them, maybe they would have a smaller touch screen, but then a higher density touch screen would be more expensive, and modifying the software to fit a smaller enclosure doesn’t make sense. Perhaps the iPhone nano wouldn’t necessarily be smaller, but even then with a hardware configuration like 2 or 4 GB of RAM, the ARM CPU underclocked to like 35o MHz to control heat, maybe 64 MB of RAM, you start to have a device that is going to have a hard time with SD video, let alone the 480p stuff you can get now, so Apple would start to lose money on media sales.
Apple is not in business to lose money. The iPhone nano idea would just be a dog. If Apple did do something like this I would advise everyone to get your money out of the stock, that ship is headed down. It would indicate panic, and an irrational view of the market, as well as an abandoning of the company’s core values.
In the absence of an iPhone nano, what is the iPhone 2,1 that is appearing in the strings in the 2.2.1 firmware? Well, obviously it has been in development for quite some time since the first time the string appeared was in the 2.0 firmware. Apple is not a company that deviates from its patterns, so let’s look at the mac laptop to determine what they might do.
Apple typically will announce a technology that is at the top of their pricing structure, then as newer equipment comes out, they will drop that item down into the next tier down, until they have about 3 items. At that point the technology that used to be new will be pushed out of their product line. Right now there is one iPhone. What is likely to happen is that they are likely to release an iPhone Pro. It will probably come in 32 and 64 MB storage units, have 256 MB of DRAM, and feature an ARMv6K CPU ( ARM11 MP Core ) with 2 or 4 cores. The iPhone Pro would feature iPhone OS 3.0 which would allow full background processes that the user could kill if necessary. The pricing would probably look something like this.
- iPhone 3G 16 GB – $199
- iPhone Pro 32 GB ( 2-core ) – $299
- iPhone Pro 64 GB ( 4-core ) – $399
I’d expect the form factor to be largely unchanged, with the same screen, shape, size and battery life. That is what makes sense, that is Apple’s style. It would then enable them to keep the high-margin, high-price item in their lineup. For Apple, the iPhone 3G is a little too cheap. It would be strange for them not to have 3 SKUs for the iPhone and the iPod Touch.