|
Written by Daniel Leiderman-Gueller
|
|
Wednesday, 21 October 2009 11:51 |
Lately I've been reading about startups and how they evolve, from being an idea to creating a product and gaining customers. One of the aspects most discussed is the value analysis of effort and result as a guideline for prioritizing actions and directions.
Results are features or capabilites that are out facing, to be used by the customers. such broad definition allows for including any task that improves or modifies the product in a tangble way so the customer can vote (with his money) on the real value. Effort is action (with time and money backing it up) internal to the company that can map to results or be purely internal.
Value proposition of results and efforts is completely different (obviously) but have something in common. Both of them are being used for prioritizing and marking something “better” than other. unfortunately, using only value proposition can be misleading and disruptive.
some major problems of value analysis are:
1. Fuziness - specially in the early stages, the value of “X” is hard to measure and can be just a guess.
2. One scale - the value proposition puts the value on one scale (better vs worse) instead of arguing the value in a multi scale according to industry.
3. Opinion - since the value is somewhat based on opinion, the results can be skewed due to other internal reasons, not connected to “X”
Since the value of “X” is can be misleading due to fuziness, scale and it being an opinion, priority analysis should be multi dimensional and include other information to complement the analysis. several ideas that come to mind are: complementary value (result and effort), different scales of value (like usability vs speed) and others. |
|
Last Updated on Wednesday, 21 October 2009 12:36 |
|
|
Written by Daniel Leiderman-Gueller
|
|
Tuesday, 13 October 2009 00:55 |
|
Our development group has a new challenge, of creating an interface to software customization group. The software customization group creates features to the main product, which are custom tailored to specific customers. One area perceived as problematic is the area of GUI modifications and addition of new capabilities. GUI modifications are regarded as hard core modifications due to the complex nature of the solution, and may be done only by the GUI team. This is of course completely incompatible with the requirement of having two different groups working on complementing features.
In order to provide a possible solution, the requirements should be clearly stated:
1. User experience should be adapted to include additional features:
(a) New views
(b) New actions
2. Adaptation should be optional
Judging other products, there is a possible solution; by using Plug-Ins. Plug-Ins as defined by Wikipedia are specific sub-applications that interact with host application. One of the reasons detailed in the article is “to enable third-party developers to create capabilities to extend an application”.
Sample applications using Plug-Ins are Photoshop and eclipse. Photoshop allow 3rd party Plug-Ins that perform new actions on the information - new image manipulation filters and new types of information exchange. Eclipse allows for Plug-Ins that provides editing of new file types, new projects and can modify every aspect of the application. For our requirements, we need the capabilities of Photoshop and Eclipse, but we need also access to central DB, where the information is stored. A similar system is SAP, where the information is stored centrally, but there are Plug-Ins for receiving and modifying information.
A Plug-In system is a plausible solution, but it needs additional refinement, mostly in definition of requirements and hooks for Plug-Ins to connect. |
|
Last Updated on Tuesday, 13 October 2009 01:12 |
|
Written by Daniel Leiderman-Gueller
|
|
Tuesday, 29 September 2009 02:03 |
|
There is a new open position in the company I work for, of managing my development group. Initially the position seemed not suitable for me, being a managerial position, but after discussing it with others I see myself qualified and capable. As obvious as it may look, seeing myself capable is not enough to be able to get the position, so I started a campaign for promoting myself and selling my capabilities of management. This is a frightening start, to initiate a change to my life.
Initially I assumed that my existing capabilities were enough and I'd be able to convince everybody of me being a suitable candidate. While convincing I found out there is a capability I lack, of selling myself. This was a big discovery for me, realizing that before I could become a manager, I had to become a sales man. Although I have experience in selling ideas, as discussed in this article on finding partners, selling myself is a different capability all together.
The realization also made me think of change, of the road I want to take. I believe in chance, that many decisions you take aren't directly connected to the path your career will develop, as I wrote in article on making career decisions. Capabilities and self growth are different as they open doors and connect you to places that were unknown or unavailable before. So now its time to learn something new, how to sell myself, using salesman techniques.
Since this learning is in a different direction, I have very few resources at hand. one of them is Brag! . but more resources are needed.
Its a maturing experience, to push yourself into a new position and learn new capabilities, even is the path is unclear. |
|
Last Updated on Tuesday, 29 September 2009 02:14 |
|
Written by Daniel Leiderman-Gueller
|
|
Monday, 14 September 2009 08:56 |
|
I’ve been following Joel On software Blog to learn about software business and see what are the challenges facing ISV. One of the interesting discussions is about desktop application vs SaaS. Although the question is quite old, since the advancement of broadband, I still believe that arguing and understanding the tradeoffs is interesting.
Here is an article from a participant detailing the reasons for moving from desktop application to SaaS, and here is an article from the SaaS Development blog. An interesting view of the differences is by using the Quality Attributes Analysis. A table with the different reasons is presented below:
|
|
|
|
|
Item
|
Desktop Application
|
SaaS
|
|
|
|
|
|
|
|
|
|
Modifiability
|
easy to modify easy to deploy
|
easy to modify but hard to deploy (needs download)
|
|
|
|
|
|
Security
|
can be decoded / decrypted / hacked
|
harder to circumvent security
|
|
|
|
|
|
Performance
|
depends on running platform
|
can be scaled to suit needs or priced for
|
|
|
|
|
|
Usability
|
higher learning curve due to different usability patterns
|
lower learning curve due to known conventions
|
|
|
|
|
|
Availability
|
depends on running platform
|
depends on web server / service contract
|
|
|
|
|
|
Testability
|
development testing is easy
but usage statistics gathering is hard
|
development testing is easy and usage gathering is easy
|
|
|
|
|
Although this analysis is very representative on technical aspects, it misses the business scope of software development. The business part of software development is completely different, its not about technical merits but about the way of making money from software. In Making money, SaaS, has many advantages that overcome the limitations.
The reasons SaaS has an advantage are:
- Easier sale: Shareware funnel is very long, thus prone to errors. SaaS has lower barriers.
- Collection of statistics: SaaS is known for collecting statistics and optimizing user experience.
last, but not least, SaaS can collect broader information and use it to make intelligent decisions and improve the user experience. As Seth Godin points, we need to stop using Dumb software, giving SaaS an edge.
|
|
Last Updated on Monday, 14 September 2009 09:22 |
|
|
|
|
<< Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>
|
|
Page 2 of 19 |
