Jan 202005
 

Stupid blogger destroyed my writing on it. And I’m too lazy to write again. So I’m just going to sum everything up.

Analysing how a successful product/solution become successful is basically what I’ve been thinking about the last few days.

To have a successful product/solution, you’ll need to have a solid Vision for it. Vision to bring the product/solution far and wide. That means you’ll have to promote, advertise, and get people to listen to you.

Next. You need to have Passion to drive the product/solution. With passion, you can bring the product to higher reaches. With Passion, you can imagine the possibilities out there.

Next. Cooperation VS Competition. For me, I’d rather choose Cooperation. Cooperation yields almost the same result as Competition. You further your product/solution to become better, you strive to be better than your competitor. But Cooperation really brings about a whole new meaning to everything. Let me explain. Cooperating will give your users/clients a better and smoother ride along your product/solution.

Next. Don’t think of possibilities. Try out unknown possibilities and see how it can start something new. What I mean is, instead of pondering how we can work together, why don’t you think, we CAN work together, let’s discuss further how we can work together even more. During this discussion or whatever, you’ll start seeing MORE possibilities coming out than you thinking of it by yourself without the other party.

Next. Possibilities are the Key to Innovation. Don’t turn away any idea or possibility that might come into your mind. Keep it. Archive it. Store it for later use. Don’t let your mind be restricted by what you can do. Possibilities are limitless, it is you who set the limit.

Next. And I think it’s the most important point. User Experience. It’s really how your user/client enjoy using your product/solution and how easy it is to use it. Don’t restraint yourself to within the box. Think and innovate outside, and new possibilities on new ways you can create your user experience. I’m not talking about fanciful graphics and such. I’m talking about a totally new concept that’s natural, easy to pick up, and it’s just simply fun to do.

That’s about all I want to say. Summed up from my previous attempt to post. I’m going to copy this post just in case. I hope someone reads this and actually finds this useful.

Disclaimer. These are my own thoughts. And some discussion points I might like to bring up. I might be wrong.

Jan 202005
 

What makes a good product or solution? It’s not your idea, it’s your vision for the product or solution. Here’s what I’ve been thinking lately.

There are alot of very wonderful and fantastic products, solutions, applications out there that alot of people do not know of. Why is that so? Because they lack the vision to promote, advertise and gain the public’s interest. Vision is very important and you have to get that straight down way before you get anything done. What do I want this product or solution to achieve? How am I going to achieve it? Not only that, which I’m going to go on to my next point here.

The next question you should ask yourself. Who and How can I cooperate with other people, companies, organisations, government? This will expand your horizons and discover new ways to improve your product/solution, and to find new ways to collaborate with your partners.

Yet another question you must ask yourself, do you have the drive to carry this out? You must foremost have the passion and the belief to carry all these out. You also need to have to come up with more plans, more ideas constantly to improve your product/solution. You will also need to think outside your box. For example, how would a totally unrelated subject/thing can help with my product/solution, or how can my product/solution help it/them/her/his?

It’s quite vague right now as it’s an idea that’s been swarming around my head. Because what I realise with Asians is that they are quite closed-minded, living in the box, and very competitive.

Another point I want to bring up also. Cooperation VS Competition. I see more sense in finding ways to cooperate than to compete. With cooperation, you co-exist and work together, helping each other in some ways or another, to improve each other’s solution/product. One must start the initiative to give first, and the other must also have the initiative to return in favour. In this aspect, each can grow in its own ways. Why compete, when you can cooperate to make something even better together? Or make the customer’s lives better by having our products/solution work together?

I’d like to bring up is to try out new ideas. Always try it. Don’t be afraid to carry it out. Don’t keep thinking of how you’re going to do it. You’ll have to solve it some day. JUST DO IT (NIKE Trademark).

Lastly, it’s to engage in new possibilities even when THERE AREN’T ANY POSSIBILITIES YET. It’s always good to sit down and discuss informally, and somewhere somehow something might come up, and we go back to the Cooperation point. Cooperate.

What I can say now is.

Possibilities are Limitless, It is Only YOU Setting The Limit.

Possibilities are the key to Innovation.

Always concentrate on the Solution, and not think about the problem.

Cheers. I hope to read this blog one day and realise what I think now is true and can apply everywhere.

Dec 232004
 

I just met up with a very business-like client who’s the total non-technology savvy person, and I must say it has been a very fruitful experience to understand the thinking of how non-techno people think.

Basically just drawing back on my previous blog, the idea of a User-Role-Centric Solution and Approach to the problem. Apparently it came to very good use as I subtlely veered her into that thinking, or maybe she already is thinking using that approach. Anyway, that’s really besides the point. But that approach actually made her able to come up with fantastic ideas for what she actually wants in her business or logic-wise. Note that we were actually talking quite non-technical here and more of what she wants to do, or what service she wants to provide the user. By thinking along that terms, she could come up with quite alot of business processes that she wants implemented, like her Invoice process, her Customer process, and so on.

From my point of view, this is actually quite a good way to draw out what your client actually wants for the solution, and how she wants it done. In my case, I would have never thought about enabling the invoice to be output into an excel file then making it available for printing, nor would I have known about how she wants herself to view the payment reports, nor would I have thought about how she wants to keep her customers by adding some added-value/services to her business, and so on. And she also has a better understanding and quite a clear understanding of how the solution works by us listing down the functionalities of what each type of person can do, without alot of the techy details. The most techy thing would be to describe the process of how the system works. As in, the user enters something, and the information is submitted into the system, and thus the system will inform the admin staff and send back a confirmation email to the user. Something along that lines. Very basic techy stuff. Nothing on like how it actually works.

Of course, the document must have these things available, in a bit more details, but that’s for another section. I actually have a Project Guidelines document which I’ll put up some time this week for you guys to look at. It’s quite interesting. But some things I might want to emphasize. Know your clients, and write your document accordingly. Safest way to do it, think in a business sense. :)

Till next time,

Cheerios.

Dec 182004
 

For those of you who know about my new project, I’ve been so damn busy working on it. This client basically wants me to come up with all the business logic and specifications of what SHE wants, but DOESN’T tell me what SHE wants, so therefore I have to predict and be a fortune-teller to come up with something that SHE’S expecting, because she herself doesn’t know what SHE’S wants the solution to do.

Simply fantastic, lamenting on this crappy project. I’m going to charge her for the consultation! Furthermore, I wasn’t there during the meeting with the client to dig out information from her, and pick out everything out of her brains.

So anyway, here’s what I’ve been researching and doing for the past few days.

I finally realised when creating a solution, one MUST think about the person using the solution itself. Trying to explain this method to my friend(s), who are in on the same project as me, made me realise the importance of a User-Role-Centric Solution. While coming up with the User-Role profiles, I realised a lot of unseen features appear that’s not realised during the so-called “feature-creation” phase, which was done BEFORE creating this User-Role profile. Which was not supposed to be the case. *DEVELOPERS*

Anyway, creating a user-role profile is basically as simple as this. Determine who’s going to use the solution. For example, in my case, we came up with 4 user-roles. The “General Person”, the “Student”, the “Teacher”, the “Admin Staff”. From this, I think you’ll have a rough idea what the type of business this company I’m doing this project for are doing.

The question to ask when figuring out what user-roles there are is simply,

Who will use this solution?

So then, here are a few questions you’ll ask yourself about each user-role.

1) Who are the people who falls into this category?

2) What does the person expect to accomplish with this solution?

3) What does the person need to have to use this solution?

4) Is there any problems with the current solution that can be solved with our solution?

5) Is there any forms of information communication between another user-role? What are they?

6) What are the tasks that the person can do with this solution?

Basically these are the few questions that one would ask the client, but apparently there wasn’t a chance to do that for my case. Therefore I had to ask myself, and my other friends this question, and see what we can come up with.

In actual fact, we realised that when comparing with our original feature-list module-seperated format, which isn’t entirely non-valid and still useable in the proposal under the section “Scope of the Project” and “Solutions Concepts”, that we actually came up with more features that we didn’t think of in the feature-list, and removed quite a fair bit of features that weren’t needed and quite redundant. Which was good, in a sense that now the entire solution was based on “what the person is able to do with the solution”, instead of “what this solution can do for the person”. There are subtle differences, but when you actually think about it, your entire specification list simply changes and morphs into an almost totally different style. WHICH IS A GOOD THING(tm). So there and then, things start to change.

And I hope you guys also follow this way of thinking, instead of plunging down into feature-list.

Cheerios. Till next time.

Dec 122004
 

Sorry guys. I’ve been so extremely busy creating my presentation slides and demo on “Generics on the .NET Framework 2.0″ and organising the Christmas Party yesterday and playing host and everything, that I’m just totally worn out.

I’ll be posting more within the next few days so just to let you guys know I’m still alive and blogging.