<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Boxes and Arrows: Comments by Manoj  Potdar</title>
    <link>http://www.boxesandarrows.com/person/8138</link>
    <pubDate>Tue, 08 May 2007 10:30:12 GMT</pubDate>
    <description>Comments by Manoj  Potdar</description>
    <item>
      <description>&lt;p&gt;Thanks Jeff and Chris for the nice informative article!&lt;/p&gt;

	&lt;p&gt;I have a doubt. How a person could plan a transition from Technical Writing profession to Product Management profession. This would typically in the scenario when the organization you are working in do not have any Product Manager.&lt;/p&gt;

	&lt;p&gt;(In this regard, I agree with the views by Paula Thornton. The struggle is keeping yourself away from being a &amp;#8216;Project  Manager&amp;#8217; or anything that becomes quite obvious for a Technical Communication professional to end up in.)&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/transitioning-from#content_7530</link>
      <guid>http://www.boxesandarrows.com/view/transitioning-from#content_7530</guid>
      <pubDate>Tue, 08 May 2007 10:30:12 GMT</pubDate>
      <author>Manoj  Potdar</author>
    </item>
    <item>
      <description>&lt;p&gt;Olga! &lt;br /&gt;One point I really agree is that an employer just want to fill the position with the &amp;#8216;right&amp;#8217; candidate. And for that they just dive into your resume and your samples. Now, here &amp;#8216;right&amp;#8217; is a very relative term which may change from employer to employer. Out of all this, we also must answer the question &amp;#8220;Are we getting what we want? Or are we just filling up the position for the employer?&amp;#8221;&lt;/p&gt;

	&lt;p&gt;In that aspect, I think, you missed the aspect of negotiating for your profile.&lt;/p&gt;

	&lt;p&gt;Cheers,&lt;/p&gt;

	&lt;p&gt;Manoj Potdar&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/getting-hired#content_14034</link>
      <guid>http://www.boxesandarrows.com/view/getting-hired#content_14034</guid>
      <pubDate>Thu, 13 Dec 2007 09:45:09 GMT</pubDate>
      <author>Manoj  Potdar</author>
    </item>
    <item>
      <description>&lt;p&gt;Hi Matthew,&lt;/p&gt;

	&lt;p&gt;Thanks for the request and the thoughts.&lt;/p&gt;

	&lt;p&gt;The last question you raised in the first para is lingering in my mind from quite some time now. Moreover, you are right in saying that usability of technical docs is not explored as of yet.&lt;/p&gt;

	&lt;p&gt;Hope to write this story and have your inputs on it.&lt;/p&gt;

	&lt;p&gt;Cheers,&lt;/p&gt;

	&lt;p&gt;Manoj Potdar&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/idea/view/13683#content_14085</link>
      <guid>http://www.boxesandarrows.com/idea/view/13683#content_14085</guid>
      <pubDate>Mon, 17 Dec 2007 09:34:37 GMT</pubDate>
      <author>Manoj  Potdar</author>
    </item>
    <item>
      <description>&lt;p&gt;Hi,&lt;/p&gt;

	&lt;p&gt;This would definitely an informative article that I would like to read. &lt;br /&gt;One more point you can cover is the balance between the heavy graphics usage and the effectiveness of the network that will be used. This makes a vital point; as the hand held devices will be accesing servers through some kind of browser or console. And you are providing the product interface on hand held devices to assit user while they are on go. In such cases, graphical components taking time to load and user waiting for them is quite an irritaing experience. As a result, testing the UI for hand held devices with the networks that possibly will be used is a must.&lt;/p&gt;

	&lt;p&gt;Regards,&lt;/p&gt;

	&lt;p&gt;Manoj Potdar&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/idea/view/14432#content_15102</link>
      <guid>http://www.boxesandarrows.com/idea/view/14432#content_15102</guid>
      <pubDate>Sat, 16 Feb 2008 13:28:58 GMT</pubDate>
      <author>Manoj  Potdar</author>
    </item>
    <item>
      <description>&lt;p&gt;Hi Todd,&lt;/p&gt;

	&lt;p&gt;Thanks for your inputs.&lt;/p&gt;

	&lt;p&gt;While exploring &lt;span class="caps"&gt;DITA&lt;/span&gt; principles to integrate Help better is a great idea, I could not understand your views, when you considered User Documents as &amp;#8216;disjointed&amp;#8217;. If you can explain it, I would be in a better situation to handle it.&lt;/p&gt;

	&lt;p&gt;Regards,&lt;/p&gt;

	&lt;p&gt;Manoj Potdar&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/idea/view/13683#content_17296</link>
      <guid>http://www.boxesandarrows.com/idea/view/13683#content_17296</guid>
      <pubDate>Mon, 17 Mar 2008 08:02:22 GMT</pubDate>
      <author>Manoj  Potdar</author>
    </item>
    <item>
      <description>&lt;p&gt;Hi Paulo,&lt;/p&gt;

	&lt;p&gt;This may be a good read. But I want to share other view too.&lt;/p&gt;

	&lt;p&gt;I have seen companies using Wiki for content generation and management. One aspect of Wiki that I found not working in favor is that anyone who got login can edit anything irrespective of authority. Wiki though informs you on the recent edit, it never stops unauthorized user from editing the content that he/she does not own.&lt;/p&gt;

	&lt;p&gt;If you can throw some light on this issue, it will be immensely helpful.&lt;/p&gt;

	&lt;p&gt;Regards,&lt;/p&gt;

	&lt;p&gt;Manoj Potdar&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/idea/view/16949#content_17299</link>
      <guid>http://www.boxesandarrows.com/idea/view/16949#content_17299</guid>
      <pubDate>Mon, 17 Mar 2008 08:27:20 GMT</pubDate>
      <author>Manoj  Potdar</author>
    </item>
    <item>
      <description>&lt;p&gt;My experience with Agile development had been positive. It was not even our own product development. We were providing outsourced product developement services to our clients. We could build and deliver as much as 70 products that went to market and clicked over a period of 4 years.&lt;/p&gt;

	&lt;p&gt;The questions put forth by Ioredana are more related to the project execution and management than that to be addressed by an ID.  The described situations arise when there is no strong negotiator on the delivery side. It requires a strong Delivery Manager who keeps the requirements realistic and work out a convinient iteration cycle time. Also, if it is a product company who using agile for development, the management having &amp;#8216;right&amp;#8217; understanding of Agile helps. Else, the engineering ends up doing shabby work against their will.&lt;/p&gt;

	&lt;p&gt;So the solution to Ioredana&amp;#8217;s questions is not an ID or any other fellow in engineering getting adjusted to whatever &amp;#8216;version&amp;#8217; of Agile thrown to you, but to get the &amp;#8216;Agile&amp;#8217; right to the basic and having a strong negotiator who understands this and keep the expectations leveled.&lt;/p&gt;

	&lt;p&gt;Remember that there are many wrong conceptions abound on Agile. But the one who understands the Agile right can only leverage it.&lt;/p&gt;

	&lt;p&gt;Manoj Potdar&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/idea/view/18774#content_21067</link>
      <guid>http://www.boxesandarrows.com/idea/view/18774#content_21067</guid>
      <pubDate>Wed, 21 May 2008 05:21:19 GMT</pubDate>
      <author>Manoj  Potdar</author>
    </item>
  </channel>
</rss>
