But also I think that the goals of the website or application that they are developing should be clearly understood. People I deal with (on the business side) have no clue as to why certain sites and applications are successful or not. They are not even sure what they really want. Wireframing is excellent but unfortunately I really suck at it. I use a marker and printer paper w/my scanner. :) Great thread.

Yeah, I completely agree. Often people start half-cocked and they are off to the races before completely understanding the market. I actually always like to start with a little strategy session first thing.

"What's the big picture vision/goal?" - needs to be narrow enough to actually focus our thinking, but big enough to allow room to maneuver. This should be the core goal of the company and probably will never change. Something like "We're going to help freelancers work more efficiently"

"What's our strategy?" - The 6-12 month actions of the company to achieve the vision. These are reviewed and updated regularly. Something like "We will create a time tracking app to help freelancers save time"

"What are our tactics?" - The steps we're taking to achieve the strategic goals. I never discuss these in executive-level meetings, because it's so easy to get bogged down. Something like "We will market the app through Reddit"

The great part is that you can validate the vision, the strategy AND the tactics pretty easily by talking to people in your market - some people are just too lazy to do that.

Great post by the way. One extra thing to think about is, who will transcribe or enter the plan into a 'to-do' list or ticket system? Most big companies use something like bugzilla to track what the programmers are doing... I'd recommend getting familiar with such a tool even if you're just hiring one guy.

What ticket system do you use? I actually choose my ticket system based on the team. I am currently using (in order of complexity): Google Spreadsheets, Streak (gmail plugin), Wrike, JIRA.

In my experience, having someone dedicated to updating/maintaining the tickets usually works much better than having everyone update themselves. I tell programmers to update status, but update everything myself.

As an employee, I started out using bugzilla, then as an entrepreneur, I had huge hassles trying to get it set up, and in the end resorted to using Mantis, simply because it's PHP based (my problems with bugzilla mostly stemmed from lack of perl knowledge).

But since then, I've actually had my guys develop a completely custom bugtracker from scratch. I did this for a few reasons:

we can have all the features we want, without the bloat we don't need getting in the way

our bugtracker is based on bootstrap by twitter, so it's very useable on mobile phones (unlike bugzilla and mantis)

it's built in to our company site so that we only have 1 website to log in to, rather than a separate bugtracker login. (This means it also ties in with other company-website functions and we can make it integrate more tightly with our repo server, etc.)

Eventually, I'll probably publish it somewhere for others to use.

In my experience, having someone dedicated to updating/maintaining the tickets usually works much better than having everyone update themselves. I tell programmers to update status, but update everything myself.

This is not my experience. The first thing we do each day as programmers (I'm also one of the 'devs' despite managing the other devs), is log in to our company site and see the tickets that are assigned to us. I mostly do the initial write up and assignment, but after that the programmer assigned to it 'collects' it (marks it as "in progress"), then when appropriate sets it to "ready for testing", etc which assigns it back to me or the default tester for that project... anyway, it works for us.

Great post. I'd just like to ad that a mockup can be pretty much anything, whereas a wireframe should only show the structure of your information and interaction with that information—no visual design. Think boxes, lines, text, arrows, and labels. The point of wireframing is to really focus on information hierarchy and interaction and not get distracted by how things will look. Wireframes should be quick and dirty, and look like it! Whoever is looking at them should by no means think they are looking at a visual design for your app/site.

I'm doing exactly this right now ! I've spent one weekend on codecademy and youtube tutorials, and now I am slowly building my HTML/CSS (with a bit of JS soon I hope !), and it is sooooo much more benefical, as it raises so many new questions.

You have no idea. Really focus on writing valid, semantic HTML. CA and YT are great resources but they wont show you everything or even a lot of best practices.

After you lock down the basics, I would recommend checking out some front-end frameworks like Foundation or Bootstrap. Both are great. I use Foundation for everything.

After you get the basics of CSS locked down, check out theSass/SCSS CSS per-processor. Some might argue with me but IMO there really is no reason to write vanilla CSS anymore. I started using it 2 years ago and have never gone back.

Good luck remember to ask questions and post some of your work to r/designcritics for some good feedback.

Great. I had a look at bootstrap yesterday, and will definitely start working with it once the front end design will look serious enough. And thanks for the subreddit r/designcritics, I will use it for some early opinions !

Where you start is with a business model. This is a great post on where to start when building a website though. Maybe share it with /r/startups too, but around here i think it's important to recognize there's more to building a business than building a website or landing page.

I like to use the business model canvas to quickly and easily see if my business has any legs. It gives you a great framework to start validating, and it's easy to change if you find your assumptions don't hold up.

People are often blinded by their own idea. To them, it's obvious (which is probably why so many beginner entrepreneurs are reluctant to share their ideas as well), so they expect everyone to understand them when they finally say something about it.

That's not to say their ideas are bad, they just aren't fully formed. They just need help with the process.

Great outline! I thought this was going to be about how to start a business (since it's in the Entrepreneur sub), but nonetheless, very relevant. It's actually a pretty good plan to follow for even starting a business. Do a mockup model on paper yourself. If you can't get through that, you probably aren't going to persist in the business.

Well, I will suggest to read Lean Startup by Eric Ries. The reason is to understand why you are creating prototypes. Its NOT for your programmers, its for your customers (THIS IS IMPORTANT). For most customers Landing page is enough to understand what's the idea is. I am completely sure if a user can get what the product is, the programmer will get how the code should be written. Then, the art of agile management will grow up. Just the product owner should communicate the idea well enough for anyone, take for example castly.co

In my opinion, if you are a programmer working for anyone... you are wasting your life. I like how programmers come on here and brag that they know everything about life... when really the jokes on them because they can't build their own company