Starting In The Front-End vs. Back-End Web Development

Having been around a lot of website & app development for the past 15 years, I see two major ways to pursue a web or app solution.

You can either approach it from the front or the back.  This just means that either the project starts with design (the front) or it starts with code and database development (the back).

Let’s just say the front-end design approach is more suited to success these days in creating a web or mobile app.  It has more of an agile (not the method, but really agile) way about it. If you are going to develop a software app, showing customers what you are going to first develop, then develop it, makes total sense.  This is all my opinion though.  When I hear that a company is going to develop all the back-end tech first and then figure out how the app will be approached from a customer perspective, I get a little nervous.  The front-end generally dictates the back-end.  But, once again, there are a lot of perspectives on this.  If we were developing 50 years ago, and were using a mainframe, we would have to build the back-end first, because there was virtually no front-end.

However, in todays environment, the largest of applications require some sort of front-end design sooner than later (preferably upfront).  I will give some great examples of success at the end of this article.

In modern web dev apps I generally see a front-side approach.  That does not mean that the back-side is not a way to develop.  It would really depend on the type of project.  It can turn to a situation where the front and back meet in the middle. That Middle approach may be a happy medium.  The Middle approach to me is just the second stage of the Front-End.

Back-End Approach

If the project is completely not dependent on customer user interface design or known business model constraints then back-end makes sense.  A good example would be developing an API.  An API (Application Programming Interface) is a way computers connection and pass information around.  So without any serious user interface, an API generally has no front-end.  But even with an API, I prefer a front-end approach, because sometimes it take a front-end to understand how the API needs to work. Another example would be a database solution that has no user interface.  Let’s face it, if there is a User Interface somewhere involved, even an administration screen, the front-end approach makes total sense.

Front-End Approach

The Front-End approach is relatively straight forward.  One tech team I work with typically will design as many screens as possible in advance, so they have identified all the necessary back-end programming needed.  Once the company or client has agreed to all these designs, they move on to an HTML/CSS version.  At the same time, they typically will start to do some of the heavy lifting back-end parts of the project.  This depends on the sophistication and complexity of the application.  So the Front-End approach ends up meeting the app code in the middle.  It’s a necessity.

The Iterative Approach

During project development, software development companies find stuff that needs to be added or fixed.  I always refer to this as the plumber who needs to open up the wall to find out what needs to be done.  No project is exactly the same as the design.  There are always slight changes, typically made by the product owner/manager. These are the fixes you could not think of initially or bugs that come into the process by mistake or because of an unexpected sequence of events (stuff you could not foretell).

After the first version of a live software project, also called a Beta or an MVP (Minimum Viable Product), there is the next version.  Typically these next versions and changes don’t always start from the Front-End, unless there is a redesign.  The next set of changes go through the same set of processes again and again.

The Final Point

Well, let’s just say that Back-End driven development is good for certain types of projects.  Let’s just say that it can lead to a major problem if the project is consumer/customer facing or consumer oriented, especially if the Back-End driven project was not developed with real customers in mind.  If the customers enter the process later, it may still be ok, especially if there is a budget to redevelop the entire project (front-end design) from scratch.  Most start-ups and divisions of companies don’t have the luxury of being like a government project.  There are many reasons why software projects fail or have to be redeveloped from the beginning.  In order to make sure this does not happen, starting with the Front-End method of development can help seriously reduce this problem.

Remember to buy my book.  Just click this link and it will take you to, where you can purchase Thinking Like A Start-Up.

Dealing with Feature Overload in Web Product Management

Simplify, Simplify Again, and Simplify a 3rd time

Having come into contact with at least 20 different websites and start-ups over the past 2 months, plus having to manage all the features in our new start-up Krowde, I am starting to see the light on the words “Simplify, Simply Again, and Simply a 3rd time”.  Back when we were at Caffeine Spaces in Boca Raton, someone wrote this on the dry erase board.  It has a lot of meaning to me and can be applied to so many aspects of building out a website or mobile app from design, functionality, marketing, architecture and other aspects of these tech start ups.  I am focused on product management in this context.  (but I could write another article on any of those disciplines)

Feature Junkie

It has a lot of meaning to me because I am a feature junkie. Everytime I come up with a new product or concept, I can think of  a million cool features.  This is what we do as creative people and when you combine that with a technologist, more specifically a web developer, you can have a thousand little features that are cool and different and meant to change the world, even a world within a world.  But overall, what you are doing with complexity sometimes, is really showing off your ego.    We all want to show off what we can do, how smart we are, and we are, but not always in business.  Trust me, it’s my downfall.  In web product management too many features and quite often the wrong features can be the death of a product or at least delay it indefinitely before it goes live.

What’s The Delay And I Want It All Now!

Now, if you think about it, how can you produce all these features when your time is limited.  That is not the real question.  The real question is what features are really needed first, and what features can’t wait.  I can’t really expound on the features in Krowde that I am talking about, but I can come up with an imaginary app that I probably will never create.  Let’s call it Park Finder, and let’s say it was being built for iOS and Android.

Anyway,  you have spec’d out the mobile app.  You have come up with a dozen great features from a map with icons, a search of that map, a link to that park’s page, a listing and a small profile per park, the ability to share that Park with your friends instantly via Facebook, Linkedin, Twitter, an ability to talk about that park, an ability to upload pictures about that park for others to see, rate that park, a list of parks by ratings, park contact info, park office instant chat.  Wait a second!  Park office instant chat.  That needs to go into the list of “Would Like” stuff.  And that is the issue.  In fact, that list has a lot of cool stuff, but ultimately his park finder app could actually be live and working with just 3 features, a search, a map and a link to the website for that park.  All the other park finder features sound so good in your head and they are, but the customers don’t know what they don’t know.

Customers Don’t Know What They Don’t Know

I like saying this line and it has come back in many conversations, because it is really important and tied to the simplification concept.   The second issue with product complexity occurs in the mind of the technology founder.  Sometimes they think that more is better.  They think that the value increases with number and breadth of features.  But it is not exactly the same for the customer or customers.  Customers don’t always think the same or use the same features.  When only 5 out of 1000 users used that feature, then of course it was not very important.  Also, from a development standpoint, what about getting the thing finished and out to the market.  That is what is important.


Getting the Park app out into the market, with limited features is the best way to do it.  It is what Fried says in Rework, Brad Feld says in his blog and it makes common sense.  If you want to get your product out there and in the market, only include at first the core features, the features that make your product usable.  It will not fail because it does not have all the final pieces and bells and whistles you envision.  It may be that the park finder app may have been well received and done very well with only these basic features.  You have the time to add new features after that.  Add your sharing, commenting, rating and other features later on.  It is painful, but worth it and the difference in your app making or not making it to market.

What Can I Live Without?

In the end people are the problem, because even I have fallen into the “I want it all” trap.  And then I was the problem. You think you can have it all, but sometimes more doesn’t necessarily sell your product.  Sometimes less does.  Sometimes doing a small thing well is more critical than anything.  There are products and services that are bigger, feature rich, etc, but they are not for the small boot strapped start-up.  There is a cost associated with more, and sometimes those features never amount to anything or any usage.  The people you can’t always control, because they may be in charge and have the purse strings.  But at least you understand yourself what the issues are, and can say to yourself, what can I live without?

The New Web Technology World Order

Outsource vs. Insource

Over the last few months and year I have learned quite a bit about Outsourcing programming overseas and the IT job market in the US.  The two are totally connected and interdependent.  And what I am finding is a conundrum.  First, the cost of software development has and will continually be driven down by offshore development, some of which I promote.  So, you would think there would be less programming jobs and therefor more technology management jobs like web web manager,  product manager, producer, project manager, Director, VP and CTO, especially to work with these outsourced teams from the Ukraine and India, for example.  Trust me these outsourced teams have moved up to the point where their skill levels are often superior to US based programmers, so we thought programming jobs would go away.

More Programming Jobs, Not Less

The truth is, there are even more programming jobs being offered all across the US and less and less management jobs, especially here in South Florida at a time when outsourcing is easy and cuts costs.  So what happened? And just understand, this is my opinion.   Well first off, even when applications are developed overseas and sit on remote websites there still needs to be an accountable local representative who can manage or oversee the deployment of the system.  This is the operations person or manager.   The biggest drawback to outsourcing is flexibility and communications.  You are not in the same room obviously, but Skype makes it seem like we are next to each other. When you have a programmer working with you in the same room  (if you were the guy or gal in charge), you are more agile and you are more likely to fix minor things quickly.  This is always going to be an issue with outsourcing.

The Heavy Lifting

The biggest positive with outsourcing is the cost and the speed of the heavy lifting.  Just think about how you paid a mover when you moved last time.  If you moved yourself, it probably took a longer time to accomplish the task, but in my experience I hired a moving company that showed up with 3 big guys who moved it all without any problem.  Same thing with outsourcing. So when there is some significant application with a lot of technology that needs to be built, sending it overseas totally makes sense.

Less Management And Not So Good For MBAs…

But more importantly I see a flattening of IT management across both large companies and SMB (Small and Medium Businesses), meaning the need and relevancy of levels of people between executives and programmers has declined.   So if you are building a building (similar to a big software program), companies, especially smaller companies, don’t see the value in hiring an architect or engineer if you follow the analogy.  Smaller business owners see the value in the construction worker and in this case the programmer, because programming value is more tangible than management value, especially during a recession.

Flying Low And Blind

Whether this is a recession issue or not, what this means is that 90% of software ventures and technology projects, especially outsourced ones, are often flying blind.  You don’t always require a project manager, but if you are spending more than $50,000 on a software project, you should have one.  If your software project has tons of features, unique pricing and other complicated parts then you probably should have a product manager.  If you are creating a product for the consumer market, then often you need a quality assurance expert.  It sounds logical, but actually only larger companies have these roles, and these roles are declining in the IT profession compared with programmer demand.  It tells me that (and I will put on my programmer hat on) that application development has gotten so much better over the years that entrepreneurs and basic users think they can take on these roles and are in fact becoming IT management experts themselves.  I have met many of them out there!  You would be surprised how may talented individuals have picked up these IT management  skills. And some people are great at this, but experience in this area can make all the difference in getting a website or product to market.

Web Feature Discovery Process – Part 1

Not that I am any bit an expert on web features, product management… and not that I know something that anybody else couldn’t figure out, but I am somewhat obsessed with the website “feature” development process, especially when it comes to overlooked, under-estimated, misused assets. This blog entry is about how I would go about discovering features and services and solutions towards increasing website traffic as well as finding new profitable directions and increasing conversion rates. I am going to give a few examples, mainly from my experience working on a site like (which is far from maximized; as far as I know they have just started the process). But first, before I describe the process to develop these features and new products (aka, the old product management process in a new era), first we have to understand the lexicon of the web feature discovery process


Assets are virtual and sometimes physical things that an organization or company owns and manages. Examples are domain names, websites, email addresses, segmented email addresses, unique site visitors, pageviews, sms, twitter accounts, Facebook and LinkedIn, Persona of the visitors (how can we break up the kinds of visitors based on background), programs and applications, patents, copyrights and internal resources like people. Oh yes, even people are assets. These assets have a value and if you don’t put a value on these assets, you are making a mistake.

You need to start the web feature discovery process by working with asset value and not revenue, because while most everything in marketing is revenue based, the overall value of what you are building towards (ultimately revenue) may be determined by the value of the assets, and assets may ultimately determine long and even short term revenue. When I say assets, many technology and marketing execs would often give me a blank stare, like they have no clue what I am talking about. (I can only chalk this up to the fact that asset value is not how they are compensated, so don’t blame them, blame the boardroom for not keeping up with current valuation measures!) But what is going on in the start-up world, whatwe can call the modern world of business, is a whole new world of asset valuation. And if your division created a website worth $20 million that only made a net income of $100,000 a year, maybe it is time to sell it and take the profits…

The second thing to know about these virtual assets are the more detail you know, and the more they are optimized, the more valuable the assets are worth. We are in a world where websites, domain names and other assets are sold off to make some cash. So, don’t overlook asset creation vs. revenue creation. They now go hand in hand. 20 years ago you would think I’m a loony bird, but the world has changed and companies do sell stuff. At my last firm they did sell assets, except not after we maximized them, but after they personally devalued them.

Often a firm may be collecting email addresses. I say “may”, because some out of the way places don’t. Good luck to those outfits. If most organizations just knew 10 things about these email addresses, what people were interested in, or simple things like their first and last names or where they are located, the asset value of the list may be double or triple the value. Add more detail detail like age, demographics, what they like, who they like, etc and increase the value further.

How do you value these assets? My way of valuing them is simple. If you were to take them away and wanted to get them back, how much would it cost you? For instance, and I am often going to use as an example, because that was the last large site I worked on. The Whois domain search site got about 2 million unique visits a month. Now the company saw no real value there because they had a hard time understanding the relationship to their sales, but when I asked execs how much would it cost you to buy 2 million visits a month by buying the PPC (Pay Per Click) words “Domain Name” and “Hosting”, it would have cost them a minimum $2 million dollars a month budget and therefor, just the traffic was worth $12 million a year or $36 million over 3 years. It’s a bit of fuzzy math, but going with “remove it and try to reacquire it”, is a great way to get them to understand. The reason most don’t understand is they typically don’t sell assets and are graded on revenue…but is that really what this is all about in the end… Because if you make something worth millions maybe the asset sales is bigger than any revenue you would ever be able to generate.

So start the process by doing an inventory of assets. First day on the job and you want to make a new web features happen at your web company, start by finding out the basics. What domains do we own? What websites do we run? What are total number of email addresses? How many visitors to each site? How many segments are we catching from customers in the email area? How many members? How many orders? How many skus? How Many? What? Where? Why and How? Get this information down on paper, because this information is the foundation for new and improved services.


Leaders, execs, people who have an idea, guys in the company basement, people on the customer service lines, MBAs with a business plan or just a lonely CEO with an idea are champions of web features. This means that somebody has to believe in it and want to make it happen. A group of people may want the features to happen, but a person has to ultimately answer and stand up and say I am the product champion. Groups don’t champion stuff, individuals do. This is one of the critical mistakes made by corporations, to think that a group of people will decide by committee ultimately what a web feature will do and how it goes is a big mistake. Not that web features are made by a dictator, and if the champion is a dictator, he probably will fail. If he is a benevolent dictator and listens well, it will succeed. Funny thing is this champion can not be limited to execs with great salaries and titles like VP, Director, CEO, CIO, CTO, BFD or Founder. A champion can and should be everybody. That is what makes companies succeed, not a special group who say only we do the thinking. It can and should by anyone, including employees, shareholders, customers, husbands & wives, sons & daughters, friends and the UPS man. Champions need support and guidance and promoters from above, below and sideways. Being a champion has its risks, as I’ve learned and you can get burned by being the champion or you can get the accolades and make it happen. You can even make it happen and not get the accolades, but then you would have known inside you made it happen. So it does not matter! Money comes later, first comes action!

Little Trees

Years ago we used to pay to plant trees in Israel. And then years later when I visited Israel I got a chance to see those trees grow. In order to grow a tree, a big tree, you have to plant seedlings or small trees. This is where many execs lose their patience and understanding of the product management process. You have to test, test and test again these little trees in order to find a big one. Ok, if you don’t get the tree allegory of ideas, you may be missing the point. Where do you find these little ideas? Somebody recently said, “Dan’s An Idea Guy!” That is not true. I am not an idea guy, I am a guy who listens and hears other people’s concepts and evolves them into ideas. There are ideas all around us, if we would take the time to just listen and sort through the data. Remember, the assets… Just doing an inventory will start to flesh out these little trees or concepts or ideas. One thing I always did at these companies is walk around and chat with the various people in the business. They have ideas. They know what may or may not work and though they don’t know how to implement, they do know something they are not telling everybody. Often its something in the business that bugged them for years that they want to share.


Never thought the web feature discovery process would come down to sharing, but learning to share, something my 3 year old has not yet mastered, is the key way towards finding those little trees. People need to get together and chat and think and find answers. These answers are something somebody read somewhere. A company environment where people don’t share their thoughts is a place that will never flesh out new concepts or web features. Look at Google, they are actually asking for the ideas and look what they have produced. If we want the rest of corporate America to be successful on the web, they better listen up and start to share. Like I said earlier, it is the champion that takes an idea and makes sure it happens, not the product management guy or gal. The product management person should be the facilitator and not the creator in the end. Listen and learn, not ignore and complain. Sometimes doing your job requires less not more of giving and taking. Learn from your childhood and share. The secret to sharing is giving of oneself. If you can not give to others, by give I mean tell people something about yourself or your ideas, you will not be able to acquire ideas. The sharing has to start with you.

The Other Guys

Now this is the easiest way to find those things that people have not thought of and get the real brainstorm on what is happening in the market. You actually need to go off and look carefully at the competitors. This is not about mimicking people, this is about concept development. You see a feature on another competitor and you grab it. Fine, but you not only have to take it, you have to own it and therefor it needs to come from you in a new way. What I ended up doing for my thesis, which you will read about in my other blog articles on Domain and Whois Tool searches. This meant locking myself up and reading through 500 websites. From this exercise alone I ended up with a dozen new products and features for the site. No rocket science involved here. It is simply looking and learning.

Integrative Strategic Thinking (Aha Moments)

Once you have all this data in front of you, such as the assets, the new ideas from those around you, and the competitive information, you now start to see things from a different level. At this higher level, as you look holistically at information. You can start to piece together stuff you did not see originally in just the assets. For instance, when I looked through and discovered that did not allow international domain name look-ups, I knew immediately this was an important issue. The importance was simple enough. If you increase upon (extend) what people already like, you will probably have success. They used to call it product extensions. This is where you take a product that is already successful and you add on a new feature or extend the product to new areas. Not a high risk activity. For, international domain name traffic look-ups blew out the traffic, automatically doubling it in six months and it tripled and quadrupled traffic over a year. Just satisfying people with stuff they already wanted is easy. However, what is easy to do, is often not seen by the blind. And when you are busy in a high end corporate product management job, you are blinded by the requests from above and from the sides.

Stats and Prioritization

What did I do with the 500 websites I viewed in my these on Whois searches? I came up with a scientific approach to figure out what feature was important. Most of you who read this probably prioritize every day. I rated each feature by value (yes a monetary value), ease of implementation, where I found it, as well as the monetary value of the websites I reviewed. This review process was not about money, it was about assets again. What I focused on, was how do I get visitors to this site, not on how do I convert. I was leaving conversion and selling at this point up to marketing and sales. That was something they knew how to do pretty well. What you need to as a good champion is to understand the data beneath the hood and how to use this data to make a point. Prioritization and hitting low hanging fruit are extremely important ways of working as well. We are in an impatient world, where execs don’t have the time or energy to listen unless they are just seeing the cream of the crop. Maybe they shouldn’t know everything till the time is right. Sometimes companies kill a product or project the first time around because it failed. That does not mean the second time it will be the same.

Learn From Your Mistakes

Organizations that learn from their mistakes and take actions the second time around to make things right are rare. Most organizations bury a concept that has failed and when it is mentioned again by an newbie, the newbie is crushed with the notion that “this has failed here”. This is a big mistake. Failure should never be viewed as a doorway an organization can not go through again. It should, however, be the shining example of how not to do the same thing, the same way. Failure should be used as a way to understand what to do right next time. Like a pyramid, building upon their knowledge, great organizations store this learned mistake information and use it positively going forward.


One of the concepts I learned while working on a well ignored site like was if you are so far behind the competition, it is sometimes worth it, to not mimic, but rather take a leap of faith and go for something greater, different, in a way that competitors would never do. Why won’t they? The competitor has already made their product or web feature decision and taken the current path. If they are leaders in the market already, it will take a lot for them to change. This leap of faith may be something like give it away for free, or combine it with something new or offer something completely different or in a way that is easy to identify but not the same. Simply cookie cutter mimicking is a nuisance on the web. Who wants to go to Bing, when Google does it so well? Why would I ever do that, other than Microsoft has figured out a way to trap me when I load the next IE Browser? Now if Bing did something so different, so incredibly well done, it would make sense. If they were better on an Ipad, sure. If they were better with voice search, sure. If they were bettter or different…it would matter. Making it matter means being different not the same. In the case of, I was determined to make the site a competitor with Sedo, the domain auction house, except my idea was to make it a free place to buy and sell domains. Sedo is not free. This is the kind of leap that makes a difference.

Hopefully this blog entry got you interested in discovering a new web feature… I will continue this blog entry in Part 2. Click Here to go to Web Feature Discovery Process – Part 2! And it turns out there will be a part 3, which I am currently working on.