Getting Your Product Out the Door: Roles, Responsibilities and Workflows

Product development methodologies you need to be successful

When should we use the Waterfall versus Agile methodology in product development, and is a sprint the same thing as a scrum?  Is there a difference between a software engineer and a software architect?  Between the IT and engineering departments?  And how do you work with these methods and teams to create the best product possible?

Paper with Question MarksThis is the third of six serialized sections of Getting Your Product out the Door: Product Development Basics. It offers insight into the terminology, assumptions and expectations of the technical part of the product development team, and best practices for building a positive and productive working relationship with them.


You’ve done your research, and you’ve discovered a niche you can fill with a great new subscription product.  Now all you have to do is . . .

Build it. Ugh. Agile versus Waterfall. Sprints, scrums and smoke-testing.  Endless pages of requirements and hours of meetings, and the product still doesn’t look like you’d hoped.  Many product owners who started out in editorial, operations or marketing struggle with the language and workflows of engineers. How can you work with them to create a good product, on time and within your budget?

Getting Your Product out the Door: Working with IT is the third article in a six-part series compiled by product owners with decades of experience in creating and launching successful subscription products.  The series is full of specific tips, checklists, examples and tools as well as best practices and foundational knowledge that will help you partner with your tech team to deliver success.

This series is written with the beginner in mind.  The content is explanatory and foundational, designed to give someone new to product leadership the practical tools necessary to help an engineering team build the product in a timely and efficient manner.  

Getting Your Product out the Door: Product Development Basics
Part 3: Working with IT

Team working togetherWorking With IT 

Without the information technology (IT) department, your product could not come to life.  Even in the days of print-only newspapers and magazines, technology ruled production.  The publishing industry moved from letterpress to offset printing and then evolved to digital prepress and typesetting technologies that revolutionized the production process.

The difference between those times and today is that the software engineers (engineers) are now an integrated part of the product development process. To varying degrees, the software, database or mobile app is the product. Therefore, it’s necessary to understand their role and how to work together.

Who Are They?

For those not used to working with IT, their roles can be confusing.  This confusion is compounded by the differing use of titles and division of responsibilities from company to company – sometimes from division to division within a company!  So, while the definitions below should help you navigate the responsibilities of various team members, always clarify your assumptions with your engineering counterpart and refer to your RACI document (from Part 2: Who Does What in Product Development?) to make sure you understand exactly who does what.




Your Relationship


Chief Information Officer (CIO)

Most senior executive responsible for the internal technology infrastructure of the company. Work with members of this team to ensure that back-office systems such as accounting are integrated successfully.

Chief Technical Officer (CTO)

Most senior executive responsible for building the technical products available to customers. The CTO or a team member will be your partner in product development.  You will approve the product from the perspective of its value to the customer; the CTO will approve it from a technical perspective.

Software Engineer

The title implies either an engineering degree or someone with a knowledge of best practices for scaling an application, including how to build it, troubleshoot, create documentation, etc. Likely your closest partner on the project; will design and choose the software, code on which to build your product.

Software Architect

Often a non-programming role focused on integrating multiple products or functional systems. Could be your liaison with the CIO’s team, will make sure the design of your new product fits into the overall platform strategy of the company.


programmer, computer programmer, developer, coder, or (sometimes) software engineer is a person who writes computer software, whether for internal or customer-facing uses. One or many will do the actual work of building your product.

Business Analyst

Identifies and documents a company’s business workflows, processes or systems, mapping the business model to its supporting technology. May help you understand your customer’s needs from a technical perspective, but will focus on identifying which data sources within the company your product will need to access, whether to gather from or contribute data and content to.

User Experience (UX) Lead

Responsible for maximizing the usability, accessibility, and overall customer satisfaction of the product. Will help you understand the best way to create your product’s workflow to maximize ease of use and meet Accessibility Guidelines.

Quality Assurance (QA) Lead

Tests the product for defects, adherence to regulatory requirements and internal use standards. Will create and execute on the testing of your new product; you will work closely with QA in the final stages of product development, and prioritize correction of the defects, or “bugs,” they find.

Database Administrator (DBA)

Database administrators (DBAs) use specialized software to store and organize data. The role can include data migration from one system to another, data security, capacity monitoring, troubleshooting, backup, and recovery. You will likely have little interaction with the DBA, but this person/team will make sure your product content is backed up, your customer information is secure and your metadata accurate.

Project Manager

A project manager is a person responsible for leading a project from its inception to execution. This includes planning, execution and managing the people, resources and scope of the project. This individual will keep you and your product on track; you will work with the project manager to ensure that all team members are delivering their work on schedule.


Who Is Responsible for Product Development?

In order to build an effective working relationship with these IT roles, it’s important to understand the function of new product development, and your role in that overall process.

Product development is a fairly straightforward activity. For the purposes of this article series, “product development” is defined as the process of responding to a lucrative market need by delineating, building and launching into the marketplace a solution to meet that need.  Deceptively simple, the successful performance of this activity will make or break your business.

So, who actually leads product development, and how does that synch up with the role of the IT department?

“[Product development] doesn’t just ‘happen.’ Your stakeholders require a shared understanding of their roles, lest you wind up with a non-cohesive team where no one will take ownership of a project, make a decision, or know how much autonomy and judgment they should exercise.” Intuit, 2015

The Product Owner 

While product decisions are sometimes made directly by the CEO or shared between sales, technical engineers, and editorial or operations teams, most high-growth organizations increase effectiveness by establishing a function specifically responsible for it – a product management team. 

The product owner is often responsible for analyzing market conditions and defining features or functions of a product in response to those conditions. The role of product management spans many activities from strategic to tactical and varies based on the organizational structure of the company. To maximize the impact and benefits to an organization, Product management must be an independent function, separate from sales, editorial or IT. 

“You should be able to articulate the highest level strategy behind a product but also be ready to explain why a particular UI element is placed the way it is.” Todd Jackson, VP Product, Dropbox 

Product management is, in many ways, an inter-disciplinary role, bridging gaps within the company between teams of different expertise, especially between engineering/IT teams and Sales and Marketing. Sometimes it’s even called the “mini-CEO role,” as successful product owners must listen carefully to many constituencies, leverage what they learn to create a clear vision of the future product, and effectively lead a team to deliver it.

As the product owner, you “own” most of the decisions about what the product will look like, the features it will have and how and when it will launch.  What’s important is that you remember that you’re speaking for the customer, not yourself and that your team members – including IT – have an advisory role because they have something to add. 

Understanding the roles product owner and IT, you can move on to building the relationship with IT. 

Communicating Effectively with IT 

Apple and Orange

While it’s not a perfect illustration, the Meyers-Briggs Type Indicator Test (MBTI) does offer some insights into the differences between product owners and engineers, particularly if those product owners “grew up” in the marketing or the editorial side of the business versus starting out as a trained product manager or even an engineer.

Traits of Product Owners

While every individual is different, those drawn to product leadership are often creative, collaborative, outgoing types who think abstractly and consider many options for a solution from a perspective that blends the quantitative with the qualitative.  Even those with a technical background are drawn to the inspirational element of transforming a customer need into a product they’ll buy. They prefer face-to-face communication and their style is often general and emotion-centric.

Traits of Engineers

Product Owner Comm

Assuming the caveat applied above, engineers generally prefer to deal in specifics. They are detail-oriented and focused on completing the task at hand. They’re drawn to what they do because they enjoy building something tangible, and meeting performance goals. Engineers often find collaborative software, IM or email a more efficient method of communication and their style is action-oriented and expressed specifically.

Clearly, there are some hurdles to overcome!

What this illustrates is the need to communicate in order to be understood and engaged by your engineers.  So, what area some specific examples of how to do this?

Provide context – but not too much. The engineering team will have great ideas how to build what your customer needs, particularly when you share your market knowledge with them.  However, too much time spent on the “soft” aspects of market need could result in you losing the team’s attention.  Keep your summary of customer motivations and the tie-back to your company’s strategic direction specific, quantitative and brief.

Collaborate. Engineers don’t exist in a vacuum; they are, in fact, part of the same industry as you are, and have opinions and ideas how to meet customer needs.  Remember, they often hear customer complaints or are asked to explain confusing sign-up or access procedures – they know where the product weaknesses are.  It’s a good idea to bring your engineers into the product development process at the ideation stage, if not out to interview customers themselves. Limit these experiences to the richest possible interactions as you want your engineers writing code as much of the time as possible.

Be precise. Your engineering team delivers a working solution to meet a customer need, which means they define every data field, place every call-to-action button and drop-down menu and, in short, build each step of a user workflow.  They can become frustrated with nebulous direction such as “we need the sign-up to be easier.”  Take the time to be specific about what you’d like while still leaving the engineer room to make suggestions.

Examples of Effective Product Owner-to-Engineer Communications


Less Effective

More Effective


Helping engineers understand the customer need.


“Our customers want unique user experiences based on their own way of using our product.”


“Our research shows that we have three types of readers who interact with us in different ways. To improve their experience based on their specific goals, we want to allow them to customize what they see by topic, frequency and author.”


Providing feedback on a registration form.


“Sign up is too complicated.”


“The only fields that are required for fulfillment and ongoing marketing are name and email address; can we downgrade the other fields to optional?”


Reacting to the design.


“I don’t like that.”


“Tell me your thought process on this design; I’m worried that the call-to-action button isn’t prominent enough.”




“I want the ability to share articles to appear ‘here’ in the app.”


“Our customers want to share articles from within the app. How would you enable that?”

Prioritize. Once you’ve crafted a response to your customer’s need (i.e., developed a new product idea) and written the requirements, it’s difficult to have to compromise. Launching anything but the perfect solution seems like a failure.  However, the realities of time and budget will always intrude, and it’s up to you to make the determination what features are “must haves” for launch, and what can wait until a future release. 

While challenging engineers to get the most possible functionality into the first version of the product makes sense, standing firm that “everything is a top priority” will only bog your project down in further delays and frustrate the team. This article will expand on prioritization methods in coming pages.

Apple Orange BalanceLet them do their jobs. Having knowledge of the data structure, software, apps and platforms used in creating your digital product is a good check on an engineering team using tools that may be personal favorites rather than the best ones for the job, but in the end it’s the lead engineer who resolves the “how to build” questions for the product.  Support the rights of the experts to make the decisions in their areas of expertise (remember the RACI chart from article 2?), while you make the decisions in yours.

Learn and support.  As you gain an understanding of IT’s workflow processes, roles and culture, your empathy and ability to communicate effectively with your engineers will increase. Being specific, prioritizing when time is short and clearly stating must-have’s as well as performing product testing and offering support during stressful pre-launch coding crunches will go a long way toward building a relationship with your tech team.

The list of responsibilities above focused on the product owner.  Likewise, you should expect the following from your engineering team:

Collaborative development. While your engineering team should be responsible for matching the right software and hardware to your product needs, it’s important that they provide insight into the strength and weakness of the options.  Collaboration is a two-way street, and you should raise a red flag if they shut down honest discussion about options, or attempts to learn.

“A design which doesn’t meet business needs is bad, no matter how pretty.” Agile Process Proverbs

4 Success Factors

Tug of WarRegular progress reporting. While progress can often best be communicated through the use of project management software such as JIRA, smaller organizations may not have these tools.  And even with PM software, holding short, regular update sessions (15-minute daily or weekly “stand-up” meetings are common in the Agile methodology, discussed later in this article) are a reasonable expectation.

Time and resource estimates.  Beware the engineering team that refuses to provide “job sizings,” or estimates of how long it will take to complete a project given a set of resource assumptions.  This is a common and reasonable expectation and IT is used to being asked.  Unless yours is the exceptional company culture that doesn’t expect project estimates, don’t be shy about them.  On the other hand – do remember that these are estimates.  Leverage your regular update sessions to keep on top of any issues that could put the delivery deadline at risk.

Understanding Development Workflows

Understanding the types of development methodology, and the principles surrounding them is an important step in working with IT.  Your engineers will likely expect to follow one of these methods, and will expect you to play your role within it. That said, no process is used 100% of the time, nor, as likely as not, will every IT department purporting to be and “Agile” shop follow the tenets of that method 100% of the time.  In a new situation, it’s best to ask. 

Development Methodology

Key Tenets

What You Need to Know



Create all product requirements, develop the entire set of requirements into a product and launch. Workflow is more of a handoff from product owner to development to marketing.

In short: write all the requirements, then build the product.

While the initial build of a new product will likely follow a Waterfall method, it may be the only time you will leverage it as it generally doesn’t fit the rapid-iteration mindset of today’s markets.


Early and continuous delivery of product enhancements in short bursts, or “sprints.” Leverage an ongoing list of priorities to release meaningful groups of new features several times a year. Daily stand-up status meetings or “scrums” are hallmarks of the Agile Process, as is the creation of “user stories” either instead of or as a supplement to traditional business requirements (i.e., “this is what the subscriber is trying to do”) instead of detailed requirements (i.e., “there should be a drop-down menu offering these three choices.”), quick cycles with small amounts of change each time..

In short: An iterative versus serial product development process.

Requires frequent communications with the engineering team as well as a strong ability to prioritize. The system most report they use today, but many businesses modify “pure” Agile development to meet their needs – be vigilant to identify the differences in your company so you can work effectively.

Extreme Programming (XP)

XP is of traditional software engineering practices are taken to “extreme” levels. As an example, checking the computer coding for bugs (“code reviews”) is a best practice; taken to the extreme, code can be reviewed continuously, i.e. the practice of pair programming.

Pair programming is when two programmers work together at one workstation. One, the driver, writes code while the other, the navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.

In short: Agile on steroids.

XP allows for continuous testing and feature changes, but can also be misused to excuse chaos and lack of prioritization.

Kanban Method

Start with the existing process, agree to an incremental and evolutionary change, respect the current process, roles, responsibilities and titles and leadership at all levels.

In short: a management style that complements Agile and XP.

Complements the other methods, to emphasize the gradual nature of change, and respect for existing roles which allowing the organization to change as it needs to.  “Kanban” should be your code word for “collaborate.”

Agile Method

While developing a new product from scratch is in many ways a de-facto “Waterfall” development – in other words, a large chunk of the product has to be created in order to deliver something meaningful to the market – you will likely work on an ongoing basis with some sort of Agile or a hybrid-Agile environment.  That is to say, as you continue to enhance your product post-launch, you’ll likely segment your product feature enhancements into meaningful chunks of work that can be released on a frequent, ongoing basis throughout the year. 

Waterfall Method

Whatever methodology IT uses for product development, there are several areas in which you will most particularly play a role.  These include creating requirements and/or user stories, feature prioritization, testing and logging issues.  These responsibilities will be detailed in our next article in the series.


HikingProduct development requires an understanding and awareness of every function of the business.  You need to know the motivations, responsibilities and communication preferences of creating, quantitative, analytical and emotional individuals and cultures, and must mix them together against a looming deadline played out in a public spotlight.  Product development is not for the faint of heart!

Keep in mind that all product development processes such as Agile, Waterfall, Kanban and tools such as user stories, business requirements, and even the titles software engineer, developer and project manager can, in practice, be performed differently from company to company. 

Team HandsThere is no absolutely correct methodology, so use what works best in your own environment.  If there’s a system or set of expectations already in place, begin by using that and establishing understanding before trying to implement your own way of doing things. And, if you don’t know – ask.

And finally, keep the lines of communication open with your IT team.  The relationship you build through your understanding of their culture and methods will deliver results. 

Next time, a closer look at building requirements, prioritizing and testing your new product.  See you then!

Wikipedia; commentary from Subscription Insider.

The Agile Manifesto; commentary from Subscription Insider.; commentary from Subscription Insider.

Up Next

Register Now For Email Subscription News Updates!

Search this site

You May Be Interested in:

Log In

Join Subscription Insider!

Want access to premium member-only content, plus conference discounts and other benefits? We deliver the information you need for improved decision-making, skills, and profitability.

Access these premium-exclusive features


$ 57


$ 397


$ 997

Interested in a team license? For up to 5 team members, order here.
Need more seats? Please contact us here.