In order to turn your online platform  or app idea into a living and breathing thing, you need to define your product. This means that you have to define "what" your product will do. The key word here is "what". There's a common pitfall when defining your product to focus on "how" you want you product to work - rather than "what" you want your product to do.   That's a very dangerous thing when building software. 

"What" is looking at the features and functions for your product. It addresses the processes, the activities, the decisions that users and the system need to make, and the inputs and outputs that will make up your product. There's a lot here, and it's key to getting the product that you want.

"How", on the other hand, looks at the design of your product - the way in which the "what" is achieved. This includes screens, user experience, technical architecture, database structures, programs.  It's all about how your product will be delivered. 

In practical terms, the difference between the two can be illustrated as follows. If you have an idea for an app that matches buyers and sellers, you might define your product by saying "I want my app to capture and store personal information about the buyer so that they don't have to re-enter it each time they make a purchase; resulting in a faster purchase time." 

Alternatively, you might say, "I want my app to have a screen with a form where the buyer enters their personal information and then when they make a purchase, there should be a button for them to use their stored information."

The first statement is based on "what" the app will do. It focuses on the activities of the user, and the expectations of the system to provide the customer with a benefit. The second statement looks at "how" you want to capture the information, and "how" the information should be retrieved.

It's not always so clear cut and it can be easy to get confused, but if you think about the "what" as being independent of any technical solution, then you're on the right track. If you start to prescribe the solution that you want the develop to build, you've ventured into "how".

The biggest reason that you don't want to define your product based on "how" is that you make assumptions about technical and functional design that may not be in the best interest of your product.   In software development, the "how" should be a response to the "what". 

If you talk about how you want things to work, it may result in your developer having to add complexity to your product that is unnecessarily or it might affect the performance of your product. This is likely to cost you more money upfront and in the future. By focusing on "what", the developer has the freedom to find the best solution to achieve your desired result.

Let's go back to our examples. If you tell your developer you want a form, there's a good bet that you'll get a form - but is that the best way to capture the information? Perhaps there's a way to get the information that results in a better user experience. Unless you have a good developer, you'll never know, because the developer will just build what you ask for.

Probably the most important reason to focus on the "what" is your customer. Ultimately, you want to build a product that does what they want it to do, and allows them to achieve the benefit that they're looking for. If you focus on the "how", there's a good chance you'll miss that piece and end up with functionality that nobody uses. 

Let's face it, looking at "how" your end product will work is pretty sexy. You get to think about what's on this screen and that screen. Making decisions about design is a lot more fun than thinking about users, tasks, and benefits. 

Yes, looking at "what" is kind of an ideal state. Depending on your budget and the developer you hire, you may have to delve into the "how" and the world of design. No problem. However, before you do that, start with the "what" first.  It's not an either/or situation.

Ultimately, your product needs to solve a problem. If you can't break down that problem, and figure out what your customer needs to do - what your product needs to do - to solve that problem, how successful can your platform or app be?