Comments on: Suggestive Selling for a Tech Comm Storefront http://www.gryphonmountain.net/2009/09/suggestive-selling-for-a-tech-comm-storefront/ Technical Communication and Other Writing Topics, by Ben Minson Wed, 11 Jan 2012 04:05:49 +0000 hourly 1 http://wordpress.org/?v=3.0.4 By: Ben http://www.gryphonmountain.net/2009/09/suggestive-selling-for-a-tech-comm-storefront/#comment-382 Ben Wed, 23 Sep 2009 22:38:05 +0000 http://www.gryphonmountain.net/?p=734#comment-382 This is an interesting idea. I hadn't thought of trying to advertise docs as development, even though in the teams I work with, what I produce is subjected to a similar process as the code. You've given me something to think about and take back to the user education team. This is an interesting idea. I hadn’t thought of trying to advertise docs as development, even though in the teams I work with, what I produce is subjected to a similar process as the code. You’ve given me something to think about and take back to the user education team.

]]> By: Arnold Burian http://www.gryphonmountain.net/2009/09/suggestive-selling-for-a-tech-comm-storefront/#comment-381 Arnold Burian Thu, 17 Sep 2009 02:15:02 +0000 http://www.gryphonmountain.net/?p=734#comment-381 I'm a big believer in the documentation team having a seat at the project team table. There are many ways to "earn" that seat, but I have found greater success in positioning the writing team as a development branch rather than as a services organization. This means taking on the responsibility of assessing the requirements and proposing a solution set. From there, you can negotiate with program, project, or product managers on a reasonable compromise. I am significantly less comfortable with being treated as a menu, from which customers can order. Still, it is a good idea to have a mechanism for demonstrating the types of deliverables you can create (at least as a reference). Interesting post, btw. I’m a big believer in the documentation team having a seat at the project team table. There are many ways to “earn” that seat, but I have found greater success in positioning the writing team as a development branch rather than as a services organization. This means taking on the responsibility of assessing the requirements and proposing a solution set. From there, you can negotiate with program, project, or product managers on a reasonable compromise.

I am significantly less comfortable with being treated as a menu, from which customers can order.

Still, it is a good idea to have a mechanism for demonstrating the types of deliverables you can create (at least as a reference).

Interesting post, btw.

]]>